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.


  • Content count

  • Joined

  • Last visited

Community Reputation

16 Good

1 Follower

About jonmoore

  • Rank

Personal Information

  • Name Jonathan
  • Location London

Recent Profile Visitors

212 profile views
  1. Agreed. I'd still want a fluid path to a third party editor, but I'm hoping the internal editor is given some love too.
  2. @sebkaine, maybe. As long as it's on sesi's radar as a workflow that needs improving, I'm happy to see what they come up with, as I'm sure there are other considerations too.
  3. I'm torn by this one as it always used to annoy me that I had to go through an interim step of opening the Houdini text editor before Sublime Text but as I've become more adventurous with VEX I've come to rely on the error messages in the Houdini text editor. Maybe an option to open both windows at the same time when using ALT E.
  4. Well put Jason. I'm also an advocate of Redshift and it's plus points go beyond the mere speed of GPU over CPU. The Redshift developers picked up on some of the finer aspects of the rendering workflow in XSI (Redshift was XSI only in the beginning) and those workflows have been brought over into other hosts. One such example is XSI strand rendering. This makes Redshift great for e.g. creating geometry at render time from curves generated via reaction diffusion/growth type experiments. Far faster than Polywire/Mantra. Redshift is also far more flexible than Octane when it comes to making use of attributes to drive your shaders. I think if you're student of an independent artist, Redshift should be at the top of your shopping list, but having knowledge of Mantra, RenderMan and Arnold will be more useful when looking for a gig. Looking at the latest benchmarks that Chaos Group put out last Friday (that included a new nVidia tech for combing GPU VRAM across multiple units) you can see why a selection of the more forward thinking studios are dipping their toes into GPU rendering. I think we're a few years away from GPU's taking over but with Moore's Law being Dodo like in CPU land, the fact that's alive and well on the GPU may mean that it comes quicker that some have been predicting. https://labs.chaosgroup.com/index.php/rendering-rd/v-ray-gpu-benchmarks-on-top-of-the-line-nvidia-gpus/
  5. I always recommend the first book - 3D Math Primer for Graphics and Game Development -. The reason I think it's so good is that it's written without the usual denseness of academically driven tomes but it still manages to have substance as well as wit. It's also really well structured. But for starters this series of web tutorials covers all the key concepts you need. Ignore the fact it looks like it was put together when Tim Berners Lee first had his idea for this new fangled thing called the Internet, it's a brilliant set of lessons and (and crib tests). http://chortle.ccsu.edu/VectorLessons/vectorIndex.html
  6. It works well as long as you're on top of the extended attribute naming conventions (as mentioned above) and was recently recompiled for 15.5.77. It's vital that you use the exact same version number of Houdini that was used to compile the version of PRTRop
  7. It's simply based on the cursor position. And funnily enough it's always reminded be of the value ladder as an interaction model. It functions in much the same way and answers the same UI challenges but for mouseless interactions.
  8. Damn fine FR. It's the simple things in life that make the most difference.
  9. I have my ENV file set up for Sublime Text and all works as it should but I was wondering if there was a way to go straight to the external editor without first opening up Houdini's internal text editor first. It seems like there's a dependency between the two but it's always nice to save a click or two where possible. EDIT: I'm using Windows 10
  10. There are some great threads here on od|force that go into detail regarding those techniques (and many with example files too). You're unlikely to use all those techniques in a single sim but the approaches should be part of your thought process when planning your effect.
  11. Most destruction artists worth their salt will talk in negative terms about 'out of the box' Voronoi fracturing because the patterns are instantly recognisable. But thats not to say that Voronoi is good for nothing. Going beyond default Voronoi is all about the manner in which you cluster those Voronoi fragments, the constraint networks and types of constraint you use (some swear by a mix of glue and cone twist), the deformations you use on edges and interior faces, and the manner in which you art direct your destruction sims via metaballs and the SOP Solver. I love the VDB toolset in Houdini but I'm not totally sold on VDB fracturing as it can be difficult to get glitch free texturing when upresing from the low poly sim. Another thing that separates the good from the average is the quality of the source model and the range of materials simulated (wood, plasterboard, concrete and brick etc, stc etc). Voronoi fracturing isn't the enemy of destruction sims but a lazy reliance on the Voronoi shelf tool is.
  12. Something which will help join the dots between math theory (and a little physics too) and 3d in Houdini is this book: Clear language, a steady pace and none of the denseness that usually afflicts textbooks. https://www.amazon.co.uk/dp/1568817231/ref=cm_sw_r_tw_dp_x_fXqHyb06VP256 And even though this 3rd edition dates back more then ten years, it's the daddy tome on proceduralism. https://www.amazon.co.uk/dp/1558608486/ref=cm_sw_r_tw_dp_x_I7qHybFZEQAV7
  13. Shiz, as I mentioned before, I think it's very valuable to apply your new knowledge learnt from video tutorials to projects of your own before moving on to your next tutorial. In doing this you'll probably learn new nodes too as seemingly simple things will take further exploration before you work out your approach (well approaches is more accurate as there's always a multitude of ways to skin the proverbial cat in Houdini!). My own take on first principles is to be fully up to speed on all the subjects in the Basics section of the integrated help system. It wasn't always this way but the help system in Houdini is a shining example of how to do technical documentation the right way. It's very well written and the integrated search enables you to instantly see VEX, HScript and Python functions from the search field itself (no need to click through to the actual page in many cases). I personally run a two monitor system and have the documentation permanently open on my second monitor (great for on the fly checking a node's local variables or a VEX function). Don't worry about going through all the examples in the basics section, although as I previously mentioned it is valuable to go through all the SOP examples (even if you don't fully understand them). What some may consider to be an advanced subject I consider a 'first principle', and thats the ability to write VEX expressions. At first this may seem a little scary (seeing as VEX is very C++ like) but you really don't need to be a programmer to get the most out of VEX expressions. However I've always believed that getting the best out of Houdini requires an ability to thing programmatically, and in my book that's not the same as being a programmer. The best places to start learning VEX expressions are the Wrangle Workshop (another Ari Danesh tutorial) and Matt Estella's VEX page on Tokeru. And whilst on Matt's site his VOP's page is ace too (and obviously related to VEX). The reason I see VEX as a first principle is that you'll be limited when working in DOP's (especially with Particles) if you don't understand how to write some simple VEX Expressions. Overall though, doing is always going to be a better long term learning methodology. Far better than passively watching or watching whilst simultaneously attempting to follow along in Houdini. With video tutorials, I think it's a three step process. 1.) Watch without following along so you don't miss any important details. 2.) Watch again whilst pausing where apt to follow along. If any of the process isn't fully explained look it up in the documentation before unpausing. 3.) Create a few new projects on your own using your new knowledge. And just to show my age, I also think it's a good idea to keep a notebook. Something like OneNote is perfect, or something Markdown based if you're more of a plain text militant type! Keeping a notebook when learning Houdini is especially useful as it can be confusing to know when to use HScript expressions, when to use VEX and when to use Python. Writing down the expressions you find useful as you go along is good start. In older tutorials Hscript is used in places where VEX/VOP's would be a better option (don't worry about this too much at first, you'll soon get a feel for it over time). If you don't come from a programming background it's especially useful to have a notebook full of useful expressions when first starting out.
  14. I think it's a little simplistic to say 'death to all video tutorials". But I agree that experimentation with your new knowledge is the best way to to ensure retention of those new tricks. A good habit with Houdini tutorials is to create 2 or 3 of your own projects based on that freshly learnt knowledge. The thing that helps things stick is that you have to solve your own problems as you go along. Another benefit of this approach is that you get to read up on current recommended techniques (here on OdForce, on the SideFX forums and in the official documentation amongst a wealth of other sources). Houdini has gone through some major changes since H12 and many of the tutorials you find scattered about the web are out of date. A classic case is the use of the Point SOP, this was a tried a tested node that crops up in a very high proportion of old tutorials. You should generally be using Point Wrangles in its place these days because the Point SOP is single threaded and it will slow your network down considerably. There are some fantastic video tutorials out there. Just be careful not to consume them in the same manner as a frenzied Netflix binge session.
  15. David, H16 is launched on Feb 6th and I suspect that there's a strong likelihood that many of these workflow issues around more traditional animation workflows are going to be addressed. There were a lot of clues given in the Roadmap presentation at Siggraph.