Jump to content

nanocell

Members
  • Content count

    46
  • Donations

    0.00 CAD 
  • Joined

  • Last visited

  • Days Won

    1

nanocell last won the day on February 20 2011

nanocell had the most liked content!

Community Reputation

1 Neutral

About nanocell

  • Rank
    Peon
  • Birthday 03/11/1984

Contact Methods

  • Website URL
    http://www.crazycoder.co.za

Personal Information

  • Name
    Van Aarde
  • Location
    Dr D Studios.
  • Interests
    Graphics programming, Visual Effects, Houdini, Rendering and simulation technology, stuff and Pizza.
  1. Have a look at this: The example hip file there shows you how to override material parameters on a per-point/instance basis. Which is most likely what you want / need for your random textures. Remember, to make things really easy for yourself, keep your texture names consistent, for example: - name all your images numerically, like: 0.exr, 1.exr, 2.exr, etc. This will allow you to override, say, a texture parameter on your shader with something like: /my/random/pics/$PT.exr Obviously, the texture name expression will become a little more involved but the above is just to get you started. HTH. CheerZ, Van Aarde.
  2. Releases

    Good news, Chris! I'm glad it was that 'easy'
  3. Releases

    I wish! I was co-developing the SOP Solver when I was still at BlackGinger so, unfortunately, the source is proprietary. But I think it would be a good idea to start with an open source one. I have been tempted to start work on that; I just haven't found the time. Hmm...this sounds familiar...I might have compiled either bullet or the DOP Solver with an additional flag to prevent any symbol omissions (Maybe try hacking your hcustom script to add the -dynamic flag). I'll try it again over the weekend and post the solution if I can manage to find it.
  4. Releases

    The bullet physics solver itself is really fast. Your biggest bottleneck is pulling in thousands of separate objects into DOPs (and this makes the DOP Bullet Solver really slow) and getting them out again. For much faster simulations a Bullet SOP Solver would be better or even writing a sim application outside of Houdini (but this will require a bit more effort to convert geometry and result to/fro). The Bullet Sop Solver solution works like a charm, though.
  5. Releases

    I found it. It was a post on the previous page (#37): http://forums.odforce.net/index.php?/topic/8101-releases/page__view__findpost__p__67916
  6. Releases

    The "trick", iirc, was to compile bullet as static libraries and link against that. The bullet libraries compile, by default, as shared libraries and it gets distributed as shared libs in Linux distros as well so you just have to make sure you are using the static libs. I think there was one tiny flag that needed to be set when doing the static linking but it has been a while; i can't remember the specifics. I'll see if I can find it.
  7. Releases

    Awesome. It's been a ages since I looked at the BulletSolver but I'll try to find some time to get it up and running and updated again. Thanks for the contributions, though!
  8. Naiad

    Yep, and chances are it would probably stay that way. mv /windows /dev/null
  9. Naiad

    The voxel grids dynamically expand as is needed by the simulation, so yes they are 'flexible in XYZ dimensions'. I would expect that all voxel representations are implemented in the same way so you can, at any stage in your network, expand or erode or composite your SDF and the voxel grid should adapt accordingly. Each "body" in Naiad (ParticleLiquid, or Volume) have settings on the container where you specify the "cell" scale to adjust the size of the cells/voxels. So it can be different for each volume in the SIM which is very handy especially when you start working with very large collision SDFs (like as terrain or mountain). <snipped>
  10. Naiad

    You are correct in that it does looks similar to DOPs, and probably functions in a similar way as well. The thing that I found to be "revolutionary" is the volumetric 'compositing' capabilities. Naiad has some pretty cool tools for manipulating volumes (shrinking, growing, inverting, and other fancy field stuff). Now, I'm not saying that Houdini can't do it; it is just infitely more cumbersome to achieve the same thing. Houdini's volume handling mechanism needs more ... flexibility? I like how Naiad doesn't limit your simulation to some predefined "volume box". The "volume box" just expands to wherever the simulation needs to go (although you can limit it with a killplane or collider or something, if the need arise). I guess Naiad is what DOPS should be .
  11. Naiad

    I have no idea whether they will be going into a public beta testing phase or it will be exclusive up to the release. I suspect they might go public, but don't hold it against me if they don't .
  12. Naiad

    Personally, I would much rather invest in Naiad than Realflow even if Naiad is more expensive (although I am curious as to what it will cost). Other than the fact that it has a node-based workflow and has amazing multithreading and simulation capabilities, they are very open with their source and tools surrounding the application whereas RealFlow doesn't even open source their plugins...lame! I think that any modern software package should embrace open source code; it is a great way for getting people to easily develop stuff for / integrate with your software...but let's leave that for another thread on another day. Also, Naiad is very fresh and cutting edge in terms of dynamics research and technology. The .ni file format will definitely be an open format. Heck, the whole gui (nStudio) is going to be open sourced as well as the command line simulator (which is apparently very few lines of code anyway) which is great! So, Naiad will basically be a closed sourced dynamics engine/library with a bunch of open source tools to use it. Great way to go for integration into any pipeline! Also, Naiad doesn't do SPH fluid simulation. SPH fluid simulations require your whole fluid to be tracked by particles, even the on the inside, which is bad news for large bodies of water. Naiad, instead, uses a hybrid approach that consist of voxel based fluid simulations and particles used for surface/feature tracking. This approach is muuuuuuch better than doing SPH fluids, especially when working with large bodies of water. Having said this, I would guess that the fire/smoke would be mostly voxel based but one never knows what tricks they might have up their sleeve. From what I've seen so far, we will be nothing less than impressed anyways The fluid surfacing functionality in Naiad is amazing and I was suprised to see how fast it was. It looks quite amazing. The more recent Naiad builds has fancy foam particle tools, wet particles and loads of other goodies! Hi-tech toys, every boy's dream! I have been working on an opens source tool to convert between the .bgeo format and Naiad's EMP format (geo2mp) and have been actively assisted by Marcus Nordenstam is tracking down and fixing bugs in both Naiad and the converter. They release their bug fixes very quickly, and often; we once went through 3 (or was that 4) Naiad updates in one day! If they can keep up this level of tech support I predict nothing but good fortune for them, and for us!
  13. Project home on code.google.com

    No problem. Collaboration is what open source is all about, after all . I've got a major code refactor from a kind contributor with additional features (i think). Hopefully we'll be able to merge things into the repository during the coming week.
  14. Hi all, I have created a project home on code.google.com for the Bullet Solver so that the project has bugs/issue/rfe tracking, wiki pages, and a place to publish binary releases. I can be found here: http://code.google.com/p/bullet-physics-solver/ The source code still remains on gitorious, though. Any contributions are more than welcome, whether it be documentation, example .hip files, help cards, code, etc. CheerZ, Van Aarde.
  15. Releases

    I have taken the liberty of moving the Bullet Physics Solver to a repository so that there is a central place for keeping track of code changes and all that. The source can be obtained from the git repository: http://gitorious.org/bullet-physics-solver/bullet-physics-solver I have attached the current source to this post. The latest source code compiles against Bullet 2.75 on Linux (tested with Ubuntu 9.04 x64, Houdini 10.0.469 and GCC 4.1.3) I have also managed to statically link the Bullet libraries into the Bullet Solver. The unresolved references was caused by a problem was in the linking order. The LinearMath library had to be specified at the end. I have attached my compiled DSO (Houdini 10.0.465 x64) for anyone that wants to try a binary. No need to even install Bullet on your system! Yay! The original sample scene is included in the source. If you have problems, start a new thread. If there are any contributions out there, feel free to throw them this way so that we can get it into the repository. I think that's about it. I'll amend here if there is anything that I forgot. CheerZ, Van Aarde. bullet-physics-solver-0.12.tar.gz bullet_solver_dso-0.12.tar.gz
×