Welcome to od|forum

Register now to gain access to all of our features. Once registered and logged in, you will be able to contribute to this site by submitting your own content or replying to existing content. You'll be able to customize your profile, receive reputation points as a reward for submitting content, while also communicating with other members via your own private inbox, plus much more! This message will be removed once you have signed in.

Thomas Helzle

Members
  • Content count

    68
  • Joined

  • Last visited

  • Days Won

    6

Community Reputation

84 Excellent

1 Follower

About Thomas Helzle

  • Rank
    Peon

Contact Methods

  • Website URL http://www.screendream.de

Personal Information

  • Name Thomas Helzle
  • Location Berlin
  1. Softimage has one of the worst NURBS implementations available, so I'm not sure if you don't shoot yourself in the foot there. If all you want to do is convert all kinds of NURBS/CAD data, I can highly recommend MoI ("Moment of Inspiration"). It's coded by the original developer of Rhino, but much easier to use, artist and Wacom friendly, much cheaper and exports very very good meshes. It imports 3DM (Rhino Format), IGES, STEP, SAT and DXF, I would recommend STEP if you can get it, then SAT and if nothing else is available, IGES. Export could be OBJ or FBX (there also is LWO but Houdinis LWO converters are broken), DXF, Sketchup and STL. I have Rhino too, but often prefer MoI for conversion. http://moi3d.com/ Don't mind the toy-like website and the simple-looking GUI, the dev actually wants to stay a bit under the radar and "simple" in this case does not mean primitive, but easy to use... ;-) For the booleans I also would wait until tomorrow... (Or do it in MoI if it doesn't need to be animated... NURBS are RAD for Booleans). Cheers, Tom
  2. Well, IMO there is a lot more that could be done. The auto-complete could also offer local variables, existing attributes and group names to prevent typing errors etc. - showing the parameters of commands would be of course the most helpful thing. Then the whole slew of helpful code editing and formatting functionality that most editors have today like editing all occurrences of a variable name at once, highlighting other occurrences if one is selected, etc. I guess we all know better code editors than the one in Houdini... More helpful error messages would also be great, often I have no clue from them what they are about. I personally will continue to hope that now that the nodes saw a lot of love, the editor is next. Cheers, Tom
  3. Thanks Iskander. While I applaud the effort I found it rather tedious to use in reality, as is the Sublime-Text extension for VEX. I guess it may work better for people who do large amounts of VEX in one go, but my code usually grows in many little steps, so all the editors that aren't directly there when I click on the wrangle make things a lot more tedious. This functionality is something that belongs right inside the core, as important as VEX is in Houdini. In every tutorial I watch on VEX, I'm told to look up the syntax in the helpfile, which is a total waste of time. I can remember the most important commands just fine after a while, but not all the variations on the parameters they have. So instead of just typing along happily like in every other good code editor, I have to stop and open the helpfile all the time. It breaks the stride and the train of thought (and the documentation isn't the most clear one I've seen in my life either...). So my FR stands :-) Cheers, Tom
  4. I haven't touched H16 yet, but if the VEX editor isn't changed significantly, I'd still make it my number one FR to have: a more fuzzy search for VEX commands in the code-intelligence tooltip - type "curve" or "point" or "pnt" and get all commands that contain those letters, even if spelled slightly different, not only those who start with it. So if you're unsure how a command was named exactly, you could go fishing... when a VEX command is entered and the opening bracket is set, show the syntax of the command in the tooltip. It is such a waste of time to always have to hunt for it in the docs. While you're at it, add some sprinkles like auto-closing brackets, a way to define how closing brackets should be indented (at the moment they are wrong ;-) ), offer to add custom code snippets ... ... simply look at some good code editors (I guess you use them to create Houdini anyway ;-) ) and make the VEX editor their equal. And one for the toolmenu: The nodes in Houdini often have very weird names that make a limited amount of sense if you are used to other packages. So one of my main struggles is, to find the node I'm looking for. Now this could be made much much easier, if the toolmenu search would be more like the one in Rhinos Grasshopper: There, you can for instance type "curve" and see of course all the nodes that have "curve" in their names, but also those who deal with curves. I guess they are doing two things there: Have a fuzzy search, that finds stuff everywhere in the node name or even if typed slightly wrong. Add a tagging system to nodes or also search through their description, so that the divide node can also be found when I search for "voronoi" (which "create dual" basically means for practical purposes), bring up the fuse node if I search for "join" etc. In Grasshopper there are tons of nodes too, literally hundreds of them are custom ones from users, but finding them was much easier because of this advanced approach to searching. In Houdini, finding the node that does what I need is one of the major hurdles and also makes exploring and discovering new things much harder. The other very very helpful thing in the toolmenu in Grasshopper is, that if you move your mouse over an entry in the list, you get a short description as a tooltip. Again, helps the newbie tremendously with finding the right node without first dropping it down, see what it does, delete it, rinse and repeat... Oh, and now that the Mantra shaders seem to look up to par with other renderers, go GPU with it... :-) Cheers, Tom
  5. Well, make sure your laptop is plugged in and on highest performance settings and not overheating, otherwise it may throttle performance. Also make sure nothing else is going on in the background that sucks up CPU cycles. Otherwise the differences should be in the range of a couple of seconds only. But sometimes it makes a difference if Houdini/the computer is started fresh or running for a long time, but it shouldn't be that much of a difference. Edit: Oh, and I found "preview" rendering slower than non-preview rendering - the hopping around of the buckets slows final speeds down it seems. It's a bit less so when you set Update Time to a higher number - I use 30 as my default. Also make sure you're not running out of RAM. I always thought 32 GB are a lot but with Houdini it's actually very little. I'll buy another 32 ASAP... Thanks a lot for your nice words - I guess many Houdini artist can relate to that :-) Cheers, Tom
  6. Sounds pretty normal to me. On my 6 core i7 from 2013 @ 4.1 GHz it takes 1:16 Minutes. Mantra is very bad at finding thin lines and only raising the main Pixel Samples will help there, not the Ray Variance Antialiasing since if the first samples don't see the line, it does not search further (same with Depth of Field and Motion Blur). So your 6 are at the low end already, not much you can do about speed otherwise. Subsurface Scattering is very slow and noisy in Mantra, so if you can get away without it, you should. The only real options to get faster renders is using a GPU renderer like Redshift and get a machine with some powerful graphics-cards like GTX 1080 TI or Titans, have several machines work on it with network rendering or using a cloud render service like Gridmarket etc. A fast main machine of course helps as well ;-) You get 3 Houdini Engine licenses for free with Indie which can be used for network rendering and network simulation in case you have other machines available. Complicated to setup but works. Mantra seems to be mainly geared at studios with powerful renderfarms, for the solo freelancer with limited renderpower it is quite hard to do animations with it. Cheers, Tom
  7. Awesome! Lots of things added that were high on my list. Houdini FTW :-) Cheers, Tom
  8. This will take ages if they start the introduction with Houdini 1, then Houdini 2 and so on... Sorry, couldn't resist ;-) Anything new in the VEX editor? Those nodes will need some getting used to... Cheers, Tom
  9. Yeah, Mantra is absurdly slow with this. Single-Frame-Cycled-Keyframe-Animation didn't work for me either, what did was using an expression like "($FF % 1.0) * 0.0025" (where the last number would be the scale of the effect) for instance in the displacement amount of a VopSop CurlNoise setup. I think I'll stick to Lightwave with that kind of stuff ;-) I think Heriberts original directions above make more sense in Houdini... Would it make sense to port the old Tomcat NPR ideas from Maya to Houdini? Basically drawing strands along silhouettes and features and do some random displacement on them to get strokes? With the fast spline rendering I use now that may be even viable speedwise. The old "invert a second mesh copy, displace along normal and render singlesided" that was discussed in the other thread didn't work for me in Mantra and/or the viewport either. But it does work in unbiased Thea Render to my surprise: Cheers, Tom
  10. Yeah, the shader is nice, but it doesn't do any displacement, that is done and animated in the vopsop... But I don't want to derail your thread with this. As you were ;-) Cheers, Tom
  11. Ok, so it seems the examples actually do not use rendertime displacement but sop-based displacement. I guess Mantra does calculate displacement only once then? Cheers and thanks! Tom
  12. And another one based on the setup by petz here: I extended it a bit and got this: Rhinos Grasshopper had pretty cool field line components, but this is even better - thank you petz!!! Cheers, Tom
  13. Following a tutorial by Alessandro Pepe on magnetic fields I came up with this: Love it - thanks Alessandro! Cheers, Tom
  14. Wow, thank you so much petz, what a great setup! I loved the field lines in Grasshopper and just recently wondered how to best go about it in Houdini... Cheers, Tom
  15. Ok, I had regular cycled keyframes but geo-samples only at 5 with the displacement texture in a principled shader where I animated the noise-offset... Good to know it's possible! Thanks and Cheers, Tom