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.

Leaderboard


Popular Content

Showing most liked content on 03/23/2017 in all areas

  1. drive.google.com/open?id=0B5Ol7zmvIewTQlRVYkN0cWVDUnc
    4 likes
  2. Hm... Im pretty sure I never had to delete any groups to make it working, but... I rarely use H and once I jump back in I tend to forget its a different soft and forget how to investigate things Yeah we do have that But if you had a chance working in max you would probably have the same. Plus need those renders by tomorrow, so its stresful Thank you so much!
    1 like
  3. In H16 we finally dropped the requirement that C and A must exist regardless of the actual file contents. This is good in a lot of cases (why create C and A when an EXR contains only Pz) and was pushed by the Terrain project. It was also the original intent of COPs, so I'm glad that this change finally happened. Unfortunately, due to the fact that this restriction has been in place for a dozen versions or so, a few cases that expect A to exist have now broken, the lumakey and chromakey among them.
    1 like
  4. It seems they don't work in 16.0.547 (don't produce any Alpha as you discovered). Only LumaMatte works. Bug submitted.
    1 like
  5. Ah yes you are right. I got rid of fluid compress sop and its meshing well no. and much faster. You saved the day twice today
    1 like
  6. If you are using the default setup, it will use the surface field as well to fill in. Thats probably what you are seeing.
    1 like
  7. Just a quick tip : 1) Create a particle sim that matches the movement / trails that you like - you may need to use a trail SOP to add enough points per frame, or use a pointreplicate. 2) Pipe the particles (with relevant @pscale * @nage type of attributes) into a cloud SOP using "Point cloud model". NB : For more visual control, you can copy a sphere to the particles first, get a visual look that roughly resembles the shape you want and then use the "polygon model" 3) Fiddle with the settings to get a nice shape and then pipe into a cloudnoise SOP to add detail. 4) Add a cloud shader and pay attention to the "scattering phase" settings to get back scattering etc, and tweak away! When I get home later I will post a sample file. Matt.
    1 like
  8. You can use an add sop and connect by attribute and enter "id". as long as there are proper id's they'll connect
    1 like
  9. One thing I notice right off the bat is that all your copies are fractured using the same exact pattern. I would start there. You need to find a way for each piece in the cabinet to have a different Voronoi pattern. Can you share a small version of your scene that demonstrates the problem?
    1 like
  10. Good question ! theoretically you can use in a (point context) wrangler : setprimintrinsic(0, "pivot", @ptnum, set(6,6,6) ); But that will move your geometry and update your "packedfulltranform" attributes into the inverse of your new pivot offset. >> If you import an alembic from Maya you get the same values on : - Point Position - intrinsic "packfulltransform" - intrinsic "pivot" >> If you export an alembic from houdini /out on which you animated objects nodes on the /obj level you get the same behaviour as the above, all attributes are updated in same manner. >> But if you have 1000 objects inside an object node and you want to tweak and set correct "packedfulltransform" + "pivot" + having the correct translation on your points, you will find out that there is some secret magic that takes : the "pivot" and tries to compensate on the point position and packedfulltransform matrix ? one to the other every time you change something . (and of course updating the packedfulltransform) -- It would be great if someone could tell us, how intrinsics update exactly ? -- Is there a way to set your own pivots that follow your pack object ? -- The "centroid" option on the "pack" node looks like the correct thing (gives you an animated intrinsic:pivot ), is there a way that can be initialized with an offset ? -- Using "origin" option on the pack node gives you 0 values on pivot, packedfulltransform and point P, but the object still moves in the viewport (voodoo?), does that mean there are other attributes that are not exposed to the user ? Thank you , Best!
    1 like
  11. There is a Mantra procedural written for it but it hasn't really been requested to be integrated into Houdini/Mantra natively yet. There will likely need to be a bunch of work done regardless . See https://github.com/dreamworksanimation/openvdb/pull/107
    1 like
  12. If you connect all four outputs of the classic shader to the computelighting inputs, what are you missing?
    1 like
  13. I am not sure I understand exactly the problem Jingaa? Looking through your scene, your object merge in bottle1 is not referencing anything existing in the scene. Also your collision geo seems to be waay bigger scale than your fluid (bottle_for_water) is this on purpose? Anyway if I redirect your merge in bottle1 to Coca_cola_bottle and then run your fluid sim (with the major scale difference) your fluid is colliding just fine. Bottle_Filling_changed.hip
    1 like
  14. Works like a charm - you guys are awesome - OD Force rules, as usual! Posted it on SESI forums as well (crediting you guys, of course) perhaps it'll help someone else with this issue some day. Much appreciated, guys! On a sidenote, I really gotta get into HOM, hehe, I've just pushed it forward for years now...
    1 like
  15. http://www.openvdb.org/download/openvdb_particle_storage_2015.pdf
    1 like
  16. Fairly sure you can do this with VDB morph. Although in my experience you'll really need some heavy machinery to work in a high quality, depending on your hardware it might not be the best option For how you would do it it's simple, you just need to animate both meshes separately, that is, the pyramid and the shoe doing their things, and then find a timing in the vdb morph that you're happy with
    1 like
  17. Hey Graham, and anyone else trying to do this I just put out a video with a little explanation of the gotchas of the process as well as the project that I showed at GDC with source files and an updated HDA (which should be going into the build anyday now) A lot of people have been asking for more info on this, so hopefully this clarifies it a bit
    1 like