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.

acey195

Members
  • Content count

    415
  • Joined

  • Last visited

  • Days Won

    7

acey195 last won the day on November 28 2015

acey195 had the most liked content!

Community Reputation

105 Excellent

About acey195

  • Rank
    Illusionist
  • Birthday 01/10/1991

Contact Methods

  • Website URL
    http://www.twandegraaf.nl/

Personal Information

  • Name
    Twan
  • Location
    France

Recent Profile Visitors

6,016 profile views
  1. Well it depends on what resolution you have, and what amount of data loss you allow (blurring) I think predicting the location of noise and having data sets for image completion (to replace the noise with) is certainly not a bad idea... There was also a siggraph demo of real-time fluids based on a similar principle
  2. if you are relying on the point numbers being the same, use attributeCopy, otherwise you can transfer based on position, using attributeTransfer.
  3. Maya and Houdini are quite different software products. If you plan on using Houdini in the long term, I would start with Houdini, not Maya, as it will be harder to un-learn the mindset you use in Maya, when you finally move into Houdini. Studying Python is especially useful for pipelines (making sure all the files are written to the correct places for instance) Learning advanced Maths is certainly not necessary for now, as long as you know what sin, cos, tan and % do in terms of math, you can do almost anything already.
  4. hmm no, unfortunately not... however... if you actually were to upload it to orbolt, it does handle the conversion for you (or at least it used to, not sure if it still does)
  5. What I do find is, if you need more and more compile begin block nodes, the gain of actually compiling the block decreases quickly, to the point where the overhead is larger than the amount of time you save. This of course depends on what you do in the loop. the more expensive the loop, the more useful it is to compile of course. But if your compiled block contains exclusively attributeVops/Wrangles sometimes it is not worth compiling at all. In your case I am pretty sure it will be worth to compile the loop, but I always like to compare the cook times afterwards using the performance monitor.
  6. Try looking at the last chapter of this video: Or if you want just to see if it works quickly, append a polywire to your fur curves and use that in Unity instead. (it will probably either not look great or be extremely high-poly if you do it this way, unless you go for a cartoony oldschool look I suppose)
  7. No an extra foreach_begin between the compile_begin3 and copypoints2, set to "fetch input" probably Edit: or to get the complete idea, watch the video in the post below, its a good one I think
  8. In this case you also need a second begin block in the foreach loop Sesi said they may change this in the future, but for now you need strict encapsulation of loops+compile blocks.
  9. use a clean node in between and possibly a divide node, to get rid of N-gons
  10. reviving this topic for a moment... Is there still no way of disabling the toggle in the Mantra Output node? In openGL it works just fine, but that doesn't run via command-line yet. When using custom format, or for 8bit data textures, where you need linear interpolation, this would be very appreciated... edit: or is THE solution to render the file at gamma 1/2.2.. which does seem like a hack to me
  11. I guess you could check for every patch if the area is equal to the width*height, if not its an "L" shape and should be split. Fixing the corner shapes is probably the biggest challenge of this pattern, while also maintaining the larger block shapes.
  12. you can also just type: @group_toExtrude = (primvertexcount(0, @primnum) < 4); //this is safer because the group will always be created (even if it is empty) that way you do not have issues using the groupPromote operation for instance //or even simpler (run over prims): @group_toExtrude = (@numvtx < 4);
  13. That one is deprecated now though, use len() instead, in the way dedeks put it. the "i[]" prefix to @ is just a way to cast the attribute as an integer array. the "Ambiguous Call" warning that you get basically tells you that you need to be more specific. see this page: http://www.sidefx.com/docs/houdini/vex/snippets (about 1/3rd to halfway down the page)
  14. Yeah, also found this out at some point. Although it sort of makes sense, as a flat plane is not a convex shape. You probably just want to use a Triangulate2D in this case
  15. nice work! like the blending of the profile as well personally I would choose for controlling: the radius(or diameter) of the tire and then set the amount of segments; which then calculates the gap. rather than what you have now, controlling: the length of the segments, the gap; which then calculates the radius of the tire. That way you can switch out patterns and still have them fit on the same wheel/vehicle.