Jump to content

jonmoore

Members
  • Posts

    42
  • Joined

  • Last visited

  • Days Won

    1

jonmoore last won the day on October 16 2019

jonmoore had the most liked content!

Personal Information

  • Name
    Jonathan
  • Location
    London

Recent Profile Visitors

1,567 profile views

jonmoore's Achievements

Newbie

Newbie (1/14)

37

Reputation

  1. Fantastic excursions into H soft bodies (they seem a perfect complement to Rich Lord's RBD excursions too). Mucho gracias for the generous knowledge share, looking forward to digging deep into your Hip's.
  2. I agree with Daryl, the main advantage of IPR renders being enabled (in Indie) in the latest V-Ray beta is that it facilitates region renders in your main GL viewport. I've got a personal preference for the VFB when using V-Ray as I like it's tone mapping features but having the ability to draw out interactive render regions in my main GL viewport makes for a fluid workflow that's more in line with Mantra and Redshift.
  3. With VEX, I found learning Processing to be a great path to learning VEX (Processing is Java based but it's still very C like but more importantly feature bespoke functions for driving graphical assets). A lot of people recommend "The C Programming Language" by Brian W. Kernighan and Dennis Ritchie (the creators of C). Whilst this is a great resource (that I think is worth getting) it's written by programmers for programmers so it's not the most beginner friendly. Personally I like using Dash on the Mac and Velocity on Windows to access the C docs (alongside over a hundred other technical docsets including Python). Much like the Python docs, the C docs has a great 'Guide' section and Dash has an integrated annotations tool where you can jot down notes (I tend to use the annotations to note specific VEX code and how it fits the rules governed by C - loop syntax and suchlike). My background was graphic design so programming used to be a barrier for me, but Processing helped me overcome my fears, and much like Processing, VEX rewards your efforts with a creative end product so as a creatively driven individual, I've found it easier to grasp than I originally feared even though it's a very C like language. The C Programming Language Dash Velocity
  4. I first taught myself the basics of Houdini by going through SideFX's excellent Quick Start tutorials hosted on Vimeo (and the multitude of videos put together by Peter Quint - even though Peters stuff is nearly 10 years old, his tutorials are still relevant and they're perfectly paced for beginners). Quick Start Tutorials And reading the Quick Start section of the documentation is essential too, it's lightyears ahead of the documentation you get with other DCC's. The most valuable part of the Quick Start docs are the 100's of example HIP's that cover all of Houdini's contexts. You'll find that many of the example use nodes that are no longer recommended (like the old Point Sop) but that doesn't diminish their utility. And as already recommended, @mestela's fantastic wiki not only walks you through all the significant differences of Houdini compared to other leading DCC's such as Maya; he supplies hundreds of well thought through example HIP files. The best thing about Houdini is that you can reverse engineer the vast majority HIP files, and this is an excellent way to learn. My only other advice is to go beyond simply reverse engineer the multitude of HIP files that are generously made available by SideFX and the wider Houdini community; but get in the habit of creating new projects based on the HIP examples you've just reverse engineered. It's only by doing and learning how to error check your own networks that new knowledge gets locked in. With so much learning material freely available, you can find yourself doing nothing other than watching videos and digging through example HIP's. Knowledge won't stick until you start applying it.
  5. All for that too, but within reason. Going atomic in SOP's is great for those nodes that contained too many disparate tools. But monolithic nodes still have their place if all the tools and functions have a natural fit.
  6. Agreed. When I first started using H16, the break up of the Copy and Group SOP's used to irritate, but six months in, they're second nature in use. More importantly, it makes far more sense to artist's new to Houdini.
  7. Gotta say, that really is badass. The look it's achieving kinda reminds me of the old NPR architectural visualisation app - Piranesi Pro (way out of vogue now, but it still has it's uses): https://goo.gl/rfBd
  8. This sounds great. The pinned post feature is working well too so this in combination would create an ace experience for members that pass by on a more intermittent basis.
  9. There's still some great interactions to be had on Discord. But I find it more useful to visit once every few days for a catch up and ensure I'm alerted to any conversation continuity on threads I've started. I'm not a fan of chat clients in general but have to use Slack for client communications so I've developed an otherwise useless skill of scanning the wheat from the chat trash. I really feel for Matt Estella. What a time suck moderating the Discord masses must be. But as ever he soldiers on with his glass half full generous spirit. He should be knighted for services to the Houdini community.
  10. In truth there are many ways of approaching generative design challenges but Houdini has two fundamental toolsets that are peerless in the realm of DCC's and algorithmic design options such as Rhino's Grasshopper: - The multi-threaded nature of VEX in combination with the Solver SOP. - Houdini's VDB toolset. Put these two together and Houdini is a generative design powerhouse. The excellent approach laid out by @f1480187 is a variation on the kinds of approaches shared by the Entagma boys/girls. If you've been following them for quite a while you need to start looking at the tutorials as departure points for your own explorations. They've shared many of the core generative design techniques you can use in Houdini over the last 12 months or so; the trick for you as an artist is to decide how you're going to combine and build on those techniques. They're not sharing magic formulas as such but more a way of approaching your design goals. Two videos they didn't share on Entagma that are worth watching, go through the way they break down algorithms from academic papers into a structure (using both VEX and nodes) that can achieve their goals in Houdini (the were shared by SideFX on Vimeo and YouTube, so you might have already seen them, even so they're worth watching again). Algorithmic Design in Houdini Houdini Day at FMX 2017 - Generative Art I believe the core of what Entagma are sharing is an attitude and approach that artists can take to solving their own design challenges. For me, that's the true value of Entagma.
  11. Head on over to Entagma. They've got a bunch of tutorials that should provide inspiration for further explorations into organic form finding. I've deep linked to a section of their tutorial selection that best match what you're looking for. Entagma Tutorials
  12. jonmoore

    Which NVIDIA GPU?

    All I can say Marty is what I'm experiencing. And the recommendation was based on more than noise. As I said, I've pretty much purchased EVGA for the last 10 years but I'm very happy with my reference design. Maybe the EVGA 1080 Ti is significantly quieter than it's equivalent 980 Ti design. I have two 1080 Ti's in my Redshift workstation and I don't find the noise problematic. But I'm using a HP Z series workstation which is pretty decent in terms of damping the noise of internal components.
  13. jonmoore

    Which NVIDIA GPU?

    I had EVGA 980 TI's (SC ACX 2.0) before upgrading to the 1080 Ti's but kept one for GL duties. If my renders don't require a lot of VRAM or when running smaller OpenCL simulations I add the 980 Ti' to the mix. The Founders Edition blower style of the 1080 Ti's are significantly quieter than the EVGA 980 Ti's (I'm very much an EVGA loyalist so a move to a vanilla nVidia design was a new route for me). I made the decision to go with a blower style design based on the advice of a few users on the Redshift forum that run GPU farms. I wouldn't automatically judge all blower style cards with your AMD experience. At the end of the day, going with most 1080 Ti designs are a good value/performce choice, just avoid the hyper overclocked designs. They're more trouble than they're worth and the price premium isn't worth it (IMO).
  14. jonmoore

    Which NVIDIA GPU?

    I'm a Redshift user with 1080Ti's and would recommend Founders Edition models as they exhaust hot air out of the back of the case. You'll be able to run up to 4x 1080 Ti's in a case without extra cooling (PCIe lane, motherboard and power supply allowing). As much as Redshift allows up to 8 GPU's in a single node, the cost of building a system capable of hosting 8 GPU's rises significantly. There are faster 1080 Ti models available with greater overclock capabilities but those gamer centric cards are not necessarily the best for GPU rendering. You should also consider something like a 1070 (or even an AMD workstation card - great performance for OpenC sims is a bonus here) to drive your GL viewport, otherwise you'll be losing a significant chunk of VRAM to system resources. With the way that GPU rendering works, if a single card has 3 GB allocated to system resources, all cards are limited to using the same amount of memory as the smallest available VRAM. Alternatively if you believe that most of your output requires no more than 7/8GB VRAM, stacking your system with 1080 Ti's alone is the best performance/price option. A final consideration is operating system. If you take a look on the Redshift forums at the benchmark table, you'll see that Linux basewd builds using the same hardware have a significant performance boost and utilise far more of the available VRAM. But don't take my word for it. Ask for advice over on the Redshift, Chaos Group and Octane forums.
×
×
  • Create New...