Jump to content

Peter Quint

  • Content count

  • Donations

    0.00 CAD 
  • Joined

  • Last visited

  • Days Won


Peter Quint last won the day on February 29 2016

Peter Quint had the most liked content!

Community Reputation

33 Excellent

About Peter Quint

  • Rank

Personal Information

  • Name
  1. POP Streams Questions

    Yes the dependency on connection order seems odd, but actually it's true throughout Houdini, wherever a merge is used, or multiple nodes are connected to a single node the order of execution depends on the order of connection. So at least it's consistent with the rest of Houdini.
  2. POP Streams Questions

    Streams are essentially a convenience method. You could set up a group and then apply a following series of nodes to that group by setting the group parameter on each node and have the same effect as the stream. The stream is neater, that's all. One use is as a state system, as the tutorial shows, but there are other uses. If I remember right the input comes into its own when you have more than one emitter in the sim. Yes the order of connection to the merge node does effect the order of execution. So if a particle is in two streams the ordering can have a significant impact.
  3. To be honest the uv tools have not changed that much, except for the addition of uv flatten. The other tools work as described in the old tutorial.
  4. Peter Quint / PQ Houdini Moving to youtube

    They've relented. I had two weeks of warnings to upgrade or have my account suspended. They've now confirmed that the rules only apply if you are charging for tutorials- so mine can stay. Thanks to everyone who supported. Peter
  5. Peter Quint / PQ Houdini Moving to youtube

    It doesn't seem to be being applied universally. I guess I'm lucky enough to be one of the larger producers of tutorials. Vimeo did contact me directly - with a message that my account would be disabled within fourteen days if I did not upgrade. I took it up with their customer services team, who didn't really engage simply repeating the terms of service back to me.
  6. Vimeo have started enforcing the rule that if you make tutorials for a product, even if you are not associated with the product's owner, and don't make money from the tutorials, you need a PRO account. So after six years on Vimeo I have a choice: to charge for videos to help meet the high cost of a PRO subscription, or move off Vimeo. I hope to have all the content back up within a week or two. https://www.youtube.com/channel/UCadDnwVUjIgXmq9XeLV05wQ
  7. Smoke motion blur from alembic

    The motion blur referred to in the video is built in to the fluid source node. It is not in this case to do with rendering. It implements the elongation of volume along the velocity similar to that described above without the hassle of building it yourself. To work the motion needs to be at the object level, not at the scene level. Here your parented animation is as I understand it at the scene level (I've not checked your file) Lay down a new geo node, dive inside delete the file node, and lay down an object merge. Set the transform to 'into current geometry' and then merge your source geo. You can then add a fluid source and get the right result. Peter
  8. A belated reply. Since that tutorial was recorded, the new Point Cloud Import by Index VOP node has been added. This allows you to use a for loop instead of a PC iterate, and thus avoid the ordering problem discussed above. You can use PC numfound to determine the range of the for loop. Peter
  9. Point Position DOP

    Not with packed primitives, but perhaps relevant https://vimeo.com/18275683
  10. Wet map

    I think it should work with a popnet. Your particles represent what is wet, you attribute transfer to some points scattered on the geometry. The Solver node is then used to manage those attributes on the points (wet points stay wet), and the shader uses a cached version of these points to shade wet or dry. I've no access to Houdini for the next ten days I'm afraid, so cant check your scene.
  11. Wet map

    Your scene is rather complicated, so it is hard to see where the problem lies. To diagnose a problem like this its important to simplify everything down to the basics. Have you managed to get the method to work using the type of simple scene I use in the tutorial? You can load the pointcloud in using a file sop, and the examine it to check if your attributes are turning out as you expect. As far as I can see the shader should work. Peter
  12. Simple pyro question.

    Rayman is right - the heat and temperature fields are closely related, and this is all about look, if it looks good use it. I suspect if you swapped the values you might get a very similar result (let me know if you don't). If either heat or temperature is low you will get very little emission in both versions of the shader above - because either the multiplier (Emission field) will be low, and/or the colour will be black, and so won't be visible.
  13. Modelling + UV Texturing Help

    I can't download your file right now, but it looks like your texturing is going to be on two fairly flat surfaces - the front and the top. You could therefore just select the relevant polys for the top part and do a planar projection, and the relevant polys from the front and do the same then you can use uvtransforms to make sure the uvs don't overlap. PS. The UV tools in Houdini are not that great - it lacks LSCM mapping for example, which would work pretty well for this kind of model. Blender does have that - so if you know Blender exporting the model as an obj file, adding uvs and then importing works fine as a method of adding uvs.
  14. You are right - Paint Export was part of all the standard shaders up to H11, but was not included in the Mantra Surface Shader in H12 onwards. I did a video on passes in H12 that looks at some of the new workflows. You can add paintExport back by editing the Mantra Surfce Shader if you really need it. Peter
  15. You need to control the geometry going in to your popnetwork node, rather than trying to do it in the source pop. So first off delete (SOP blast) any ponts not due to emit that frame (use an expression of the kind $FF < $EMITFRAME && $FF + 1 > $EMTFRAME - assuming emitframe is the frame attribute). You can them simply emit a particle for each incoming geometry point (use impulse emission with $NPT as the particle count). Controlling the number of particles emitted per source particle is slighty harder. You could probably duplicate up the incoming points using a foreach sop, or use groups and a split sop in pops.