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.

tfreitag

Members
  • Content count

    60
  • Joined

  • Last visited

  • Days Won

    2

Community Reputation

41 Excellent

About tfreitag

  • Rank
    Peon

Personal Information

  • Name Tom

Recent Profile Visitors

3,241 profile views
  1. thanks eetu btw. I have recognized that you have been active member in the demoscene. So you did stuff for organe tv and coma? I've been also active member around 2000 ...the groups from finnland delivered the most crazy and also best demos! But now you transfer the spirit and passion of the demoscene to the houdini community (i.e. your long rnd thread). Nice to see.
  2. hi everyone, i would like to share my latest houdini work. the initial motivation cames from entagmas strange attractor tut (thanks!). based on thomas attractor i build up three force fields to get this kind of complex structures. listen to the music with headphones. tom.
  3. i bought month ago the 6950x. its running like hell. really! i overclocking it easily to 4 ghz. for me it is worth the money. i think its the best compromise between amount of core and single thread perfomance. and whats astonish how much nodes are multitreaded right now. its not only rendering, but the daily workflow becomes really fast. i.e. flip or pyro (with no collision geo) using all the 40 ghz
  4. what a great release! it must be huge amount work of the dev team in 9 month. i really love the "small" features like the foreach loop, visualizer node... but also pyro3 shader , new disney shader, fem 10x faster, bullet is faster, adaptive grain and so on...crazy! i wish sesi best success...and a lot more customers/artist, then more studios would integrate it in here pipeline.
  5. Only the additional CG smoke were rendered with mantra. The car was shaded and rendered in Max/Vray. The packshot of the car is studioshot.
  6. thanks guys ! I have to say that I'm really fall in love with the pyro 2 shader. First I tried the advecting-tons-of-particle-workflow and bring it to krakatoa, but it was much easier and I getting a better look with mantra and pyro-shader.
  7. hi, i want to show my first commercial job with houdini. I did all the cg fluid stuff with pyro and rendered in mantra. i really enjoyed houdini in production. its mostly mixed with real footage. tom
  8. great execution! I love the athmo
  9. haa! thanks eetu (and of course jordi) for the link ..after spending serveral hours try to rendering volume with max imported camera, this is nice trick, with blend node. ...and its page 118.
  10. thanks for reply. everything is build around the foreach. so i have to use it. but anyway, i got some help at sidefx forum: https://www.sidefx.com/index.php?option=com_forum&Itemid=172&page=viewtopic&t=16600
  11. hey, so this simple problem driving me crazy. So I have a "For Each" driving by an attribute. Inside I am using a attrib promote to sum up a point attribute as SUM in details. All are integers. Here is a example. Iteration detailattrib result (sum every iteration) 1. 5 5 2. 3 8 3. 2 10 4. 4 14 .. My idea: sum=sum(current iteration)+sum(last iteration) BUT I can't using "MERGE RESULTS". I have found a thread, where Jeff uploaded a sample file. But in his file the iterator summation works only with foreach in feedback modus. But I don't want it. any help woudl be great thanks in advance. tom summation_insideforeach.hipnc
  12. Germany: RiseFX in Berlin are uising Houdini for VFX and Lightning&Rendering. And Sehsucht in Hamburg seems to make a transition from XSI to Houdini.
  13. OK, the mesh I got have some open faces. So a fuse did the job. Sorry for the alarm.
  14. Hello, so the alembic driving me crazy sorry for open a new thread, but it seems a serious problem. I have my fish crowd with three different fishes. On two of them in the viewport everything is ok, but when I render on the fishes appear little spheres. I think it render some point as spheres. What is it? I don't know what to do. here are my abc files: https://db.tt/Sf6KshuR the kingfish and dorade are damaged. the barracuda thanks. tom
  15. The support tooks a look inside my hipfile, with allso very great and helpfull information about abc format. So that everyone could benefit I will post it here: " The issue is the Alembic output node is getting confused when trying to match the packed primitives from frame to frame. So, it's creating new geometry on some frames (since it thinks the topology is changing). I was able to work around this issue by: - Add a new stamp parameter, I called mine "number" and set its value to $PT (the point being copied to). - Insert a pack SOP before the copy to manually pack. Setting the path attribute to << op:`opfullpath('.')+stamp("../ copy1", "number", 0)` >> - Turn off Pack Geometry in the copy SOP - In the Alembic ROP, turn on partitioning geometry by attribute - Set the attribute name in the Alembic ROP to "path" This helps the Alembic ROP match primitives since the path attribute matches. Without this change, when I saved the Alembic, I was getting 5000+ shape nodes in the .abc file (over 20 frames) when there were were only 1685 points. After the above change, there are 1685 Alembic primitives when I load it in. When I read in the Alembic, the geometry also matches. We'll try to figure out why the Alembic ROP isn't able to match geometry properly though. Also, with your current set up, you may not be getting ideal instancing in Alembic. For instancing to work, you'll need to have the same shape duplicated multiple times. Since you're doing blending of the copied geometry, your likely getting duplicated geometry. In addition, with stamping, you're unlikely to get shared geometry between copies unless you turn on "Cache Stamping Geometry" - which will compute all the different stamping possibilities and create "shared" versions of the geometry for stamping. Of course, since you're using floating point parameters for stamping, you're likely not going to get duplicate geometry there either. Even if you were able to have shared geometry, the instancing in Alembic works across all frames, so it's quite possible that if the geometry is shared, then unshared, this would cause big hiccups in Alembic export (a shared instance needs to be shared over all frames)."