Jump to content


  • Content count

  • Donations

    0.00 CAD 
  • Joined

  • Last visited

Community Reputation

0 Neutral

About peship

  • Rank
  1. Yeah Cell.... Yeah Again

    nVidia has great products. No question about that. What i meant is - if Intel puts a strong GPU module(s) in your CPU, then what's the point of buying a video card with GPU ? It seems that Intel is on the right track these days, if they keep it up, then nVidia will suddenly join the AMD club. EDIT: spelling
  2. Yeah Cell.... Yeah Again

    Sony funds sidefx to port Houdini to Cell, but the first step of the roadmap is to get Houdini multithreaded. Does not matter what the destiny of Cell will be - we should get one better multithreaded Houdini out of this. From what i hear Intel cooks some realtime raytracing built into their CPUs ( and if the rumor is true - this will not be the half baked i740 chipset, but the other way around ), i think nVidia will have some real problems soon - they seem to start freaking out already.
  3. export houdini animation to maya

    For geometry with chaning poing count over time i would do something like this ( assume we ignore the Maya API to streamline the task ): export the geometry per frame from Houdini as .obj file sequence. create a reference in maya and point to this sequence of files. script the path/file reference string to switch the files according to frame number. create an empty mesh node. each time when reloading the reference script_connect it's outMesh to the inMesh of this empty mesh node ( or maybe once done, maya keeps the connection - cannot remember anymore how exactly it worked, but either way it is not a problem ). This workflow creates a stable point ( the mesh node ) from where to start building your graph network. It's like the fileSOP in houdini, but little clumsy. As far as i can remember some version(s) of Maya had problem directly referencing .obj files, if you have the bad luck of using one of them, you will need to convert the .obj sequence to .mb or .ma format. ... problems with motion blur ...
  4. Houdini Cloth Or Syflex Plugin

    Oy, i see now. You are right. Taking back my "ridiculous" words.
  5. Houdini Cloth Or Syflex Plugin

    Syflex is good for digital doubles. It's fast, accurate and stable. It's not that good for full blown CG characters. They usually have multiple layers of cloth, but Syflex does not solve cloth to cloth collisions. To claim that H Cloth is faster than Syflex is ridiculous. Syflex for Houdini is actually the very first version of the cloth system. It lacks many useful features from the latest releases - like the magnet constraint, that gives nice directability during simulation time. H Cloth solves cloth to cloth, so if you have to deal with layers of cloth go for it. It is slow and lacks flexible constraints.
  6. C++ Help Required

    This one works really well: http://math.nist.gov/sparselib++/
  7. Tenthdimension

    strings strings ...
  8. Holding Weights In Houdini

    Hi Kenny, if i get your question right, the answer is yes. I think a good idea is all captureWeights related tools to do the normalization automatically, there is no reason to go outside of the 0-1 range. I didn't know that you and Jeff have been involved in the design process of the character tools. But, good job guys - really. True. I am sure you realize how big hassle is this workflow for such a simple thing as locking weights during paintCaptureWeights. It automatically excludes itself as practicaly working solution for this purpose. Can you imagine doing this 20-30 (or whatever random number) times for each bone everyday, for different sets of points ? Will be better to make the paintCaptureWeights SOP do something "on fly" without leaving a trace in the history and without bothering the user, because it's not needed - the end result is either way just weights, how you generated them inside the paintCaptureWeights SOP does not matter - it's not procedural anyway. Hi Arctor, you are right about the capture layer paint system - it is really well done, bad documented and sometimes more complicated than needed ( not necessary a bad thing ). And yes, most of the time characters and proceduralism do not live in the same world, but that's ok.
  9. Holding Weights In Houdini

    editCaptureWeights is really good at what it is doing. The initial question in this thread was about having ability to lock skin weights for some of the bones when in paintCaptureWeights context. This allows the weights of many points to be fine tweaked in a fast and convenient manner. In most cases this will make the editCaptureWeights little obsolete, or at least used less often - mostly when needed to clean-up few points here and there. Painting of skin weights is very time consuming and annoying, so any speed-ups are welcome. Two examples from the top of my head: Bunch of points weighted to three bones. You like how bone1 deforms them, but bone2 has too much influence, so you can lock the weights of bone1, then start painting the desired points weighted to bone3. If you try painting weight equal or above 1, this will completelly wipe the weights of the other unlocked bone(s), but the final weight of the painted bone will be equal to 1 - theLockedWeights. Wide areas can be covered in no time. Or if you want to smooth weights only between bone 2 and bone3 - then again - lock bone1 then paint (smooth mode). if you dont have ability to lock certain bones, the smoothing will mess-up everything. And so on ... It is as simple and convenient as this. And very usefull. AdamJ: I am well aware of this list, it works great if you have 20-30 bones in the scene, but when doing heavy rigging wich often goes way above 100+ bones the list is getting really looooong. And finding anything in it is getting hard. I dont know about you, but along the years i used many tools trying to figure out better ways of dealing with this issue - logical splitting of bones in sets or separate lists, hiding/unhiding of these logical groups, isolating in the viewports sets of bones, etc. No one really solves it to a level that suites my needs well enough. A direct feedback in the viewport does mutch better work than scrolling up and down in the UI. Trust me - it makes quite a difference. These, i think, are relativelly small features, but while all 3d animation applications have all big things implemented already, the little ones make the difference. Jeff, i am sorry if my words sound too harsh. This is totally not the point. If you can convince the developers to implement better constraints, you will gain lots of good karma. And you really got me surprised that you still keep notes from our conversations at DNA All best !
  10. Dynamic Chains

    Not really sure what exactly you want to do, but why not using the curve as animation path for bunch of bones or directly for the chain pieces ?
  11. Holding Weights In Houdini

    This little feature is improtant. Most people will not even notice it in the "what's new" list, but the guys who care will recognize it. Often it makes quite a difference in tough moment. In fact many riggers completely rely on it. While we are talking about this kind of stuff ... Right now in H, if you have bunch of bones on top of each other, there is no easy ( fast, convenient ) way to select-paint the desired one. I actually can remember talking with somebody ( or maybe chattering on this forum ) about it and was told something like "why you would need multiple layers of bones ?", which is a clear indication that somebody up north is totally missing the point. No offense, total respect.
  12. Hair Modeling

  13. Hair Modeling

    I will check for that file tonight. The warning messages have something to do with trash in the scenes, carried out from an old H release(s) which had some problems with this kind of stuff - just ignore them. And thanks for the kind words
  14. Hair Modeling

    The old school hair styling app is ShaveAndAHaircut. But these days Cinema4D offers better tools. Both they are good to edit multiple curves at once, this way you can model the big volume of hair ( or wide areas covered with hair/fur ) relativelly fast. If you need to mach some exact look, the last stage is always pushing points by hand - usually this happens in the software you plan to use for simming the hair. Many people/studios stick to the points pushing approach only. http://www.petershipkov.com/temp/longHair1.0.tar.gz ( ~37 Mb ) The archive contains otls, example scenes, motion captured animation, two image sequences showing the stuff in motion ( no hair style or whatsoever ) and bgeo file with much better looking hair. In fact i am not sure if that's the exact content, but should be. As the most personal projects it misses the last 10% - usually good looking examples showing what the product is capable of. Which is understandable - at the moment i proved to myself that the thing works i lost interest The good looking hair geometry was supposed to be the missing 10%. I am using the default vex hair shader - it is not very good, but i had problems with Arno's hair stuff ( he gave me permission to use it ), it keeps saving the otls inside the hip file, even i instructed H to not do that.
  15. Hair Modeling

    Steve, i am sorry for the delay. Yes, i use other software to style the hair. And it's not just to get some rough shape, but for really fine tweaking - literally point-per-point adjustments. In addition are needed lots of deformers, dynamic goals, cache blending, hand animation, etc - otherwise the things simply do not work well ( talking about long hair here, but even for fur you need quite a bit of the same before running the solvers ). Tonight i will give you a link to the stuff i promised.