Jump to content


  • Content count

  • Donations

    0.00 CAD 
  • Joined

  • Last visited

Everything posted by peship

  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.
  16. Hair Modeling

    Well, i think i can help you a bit here. I will tell you what i did ago and hopefully this could be helpfull in one or another way for you. It's the common workflow - startCurve, restCurve, dynamiCurve + per-primitive/per-point control + tools to manage the data and objects. The data flow is split between hairSystem, hairFollicle and hairClump operators. The hairFollicles contain the dynamic/rest/start curves. You can use ( edit/reshape ) the built-in curves, or connect to the follicles geometry containing curves modeled in other 3D apps, each hairFollicle will pick-up only one unique primitive from there. These operators allow and fine tuning of the dynamic properties of the curves using constant values or animationCurves ( for per-point control along the curves ). The hairClumps contain the actual curves which will be rendered. These operators basically "instance" geometry along the dynamicCurves, add some variation to the shape, thickness, color, shaders are applied to them, etc. All the hairFollicles get connected to hairSystem node. It collects all the dynamicCurves and sends them to the DOP network, DOPs do something with that geometry and send the simmed data back to the hairSystem. The hairSystem propagates the changes to the follicles. Also hairSystem allows global control over the whole hair setup. The workflow is based on overriding of settings and is like this: set-up the globals from the hairSystemOp, then tweak here and there using hairFollicle and hairClump ops. Also, the hair operators can read pointAttribs from the scalp geometry to which they are stuck to. So you can paint baldness, scale, color, dynamicProperties, etc along the surface. It can get really slow tho. Anyway, this is simply another level of control over the look/behaviour of the hair system. I can go into more details, but at this point i feel it is not neccessery. If you are somehow interested i can handle you the stuff.
  17. Houdini Tools

    I double that.
  18. Flight Patterns

    awesome !
  19. Creating Maps From Fluid Sim

    I dont think you can generate additional comp elements directly from realflow. You need to bring the particles/meshes in MAX, apply shaders, expressions, render them nicely, etc.
  20. Creating Maps From Fluid Sim

    Export meshes with sim data baked to the point attribs, write shaders to pick it up and render it as additional color coded passes. A good approach for foam ( or whatever other ) maps is to bring the rf particles in your main 3d application, color code them based on the sim data and render additional passes. A skilled comper can make a great use of them. As i side note - having rman with it's deepShadows is very helpfull for rendering of dense point clouds and making them look like water. These are general rules and they apply to basically everything, not just realflow. Saying that, i assume you dont have programmers at hand. Realflow has many data i/o limitations and extracting usefull information from what comes out by default from it can be a pain. If that's not the case, then writing a custom exporters to bake all the needed data directly in the meshes will solve most of your problems at once.
  21. I found something very disturbing, let me explain it shortly ... The channel editor - i have an animation curve with to say 3 keyframes. Now i want to change the curvature type of each key - the first one to be bezier, the second one to be linear and the third one to be spline. What the UI offers me, is to affect the whole curve segment between two keys instead of affecting the keys directly. On top of that i cant find a way to control the in and out curvature of each key. Please tell me that i'm wrong and there is a way ! Thanks.
  22. Spent time today to check over internet what kind of options we have when it comes to fluid dynamics. I was surprised to see so many implementations all over the place. Each of them showing as mutch muscle as possible So here is the list with commercial software: dynamite for LW3D - http://www.cantarcan.com/v11/html/main.html fumeFX for 3DS MAX - http://www.afterworks.com/FumeFX.asp Aura for 3DS MAX - http://www.spot3d.com/AURA/movies/ ( cant find the official page ) FlowLine for 3DS MAX and Maya - http://www.flowlines.info/index.html MayaFluids - http://usa.autodesk.com/adsk/servlet/item?...&id=7636671 ( cant find any eyecandy over autodesk.com ) RealFlow - http://nextlimit.com Glu3D - http://www.3dalliens.com Blender http://mediawiki.blender.org/index.php/Main_Page Myrtle Software - http://www.myrtlesoftware.com/index.php/home ( seems that along with the voxel renderer, there is and a CFD solver ) R&D stuff: Houdini9: http://www.sidefx.com/images/stories/news/...ak_peek_web.mov - impressive stuff ! Fluids for XSI - http://grabiller.3dvf.net/site/index.php?l...fluids_eng.html Found this russian web site with screenshots from Alias's conference this siggraph. They are showing their "unified dynamics solver" + level sets and stuff. http://www.cgtalk.ru/forum/showthread.php?t=13728 Jos Stam's web page about stable fluids: http://www.dgp.toronto.edu/~stam/reality/T...v3_document.htm http://graphics.stanford.edu/~fedkiw/ - no comment - as far as i know he is doing some work at ILM aside of his research. really cool 2D solver written on Java ( click with the mouse over the white square ): http://www.multires.caltech.edu/teaching/d...tablefluids.htm Mark Carlson - http://www-static.cc.gatech.edu/~carlson/ ( i had the pleasure to work with this guy - wicked smart ) Frantic Film's "Flood" - http://software.franticfilms.com/index.aspx?page=flood ... i will stop here. In case i missed a cool link - update me
  23. A List Of Software For Fluid Dynamics

    spent a moment today to update the list with fluid solvers. the fluids video over sidefx.com looks really impressive.
  24. Can You Animate Variables?

    i think they are looking more for something like variable variables in PHP.
  25. A List Of Software For Fluid Dynamics

    Some cfd solvers are not really colliding with geometry. Instead of that they are filling the densities of the voxels inside the penetrating geometry and because they are incompressible fluids this dense area will push the stuff around. The negative side of this approach is that you will lose lots of volume ( density ) in the areas around fast moving objects through the fluid container. So i am wondering, is what we saw the same trick with high-res grid / high-quality solving to minimize the density loses, or the real thing ? As far as i know there are some technical issues with the coding collisions for navier-stokes solvers.