Jump to content

CiaranM

Members
  • Posts

    48
  • Joined

  • Last visited

  • Days Won

    1

CiaranM last won the day on December 1 2015

CiaranM had the most liked content!

Personal Information

  • Name
    Ciaran
  • Location
    London

Recent Profile Visitors

2,865 profile views

CiaranM's Achievements

Newbie

Newbie (1/14)

8

Reputation

  1. Agreed, many an explosion has been rendered with a nice black>orange gradient that will make the blackbody shader look like the joke it is.
  2. You could try using the "op:" syntax to point to an operator in the scene. Never tried it though...
  3. You could potentially edit the primitive intrinsic "unexpandedfilename" if all of your high resolution pieces are saved to disk individually. This can done in vex, but some info can be found here: https://www.sidefx.com/docs/houdini/nodes/sop/packeddiskedit.html This does not have to be done on packed disks only, but also works fine on packed gometry.
  4. Well, for starters, I'd use Bullet and forget about wire solvers.
  5. CiaranM

    colored Smoke

    Oops! I guess I didn't hid the attach button last time... pyro_color_advect_update.hip
  6. CiaranM

    colored Smoke

    Fencer, your solution is close but missing a few important details. In your setup you're adding a Cd vector field from the SOP source, but only at the start of the sim. You need to intoduce a source to continuously add values to the Cd field. By just normalizing the output, you'll magnify really small values where the color has prviously been advected through. If you do something like add another emitter later in the sim or animate one of the emitters you'll get really weird results. One simple way to source color is to remap the vector field of the sourcevolume DOP from velocity to Cd. You might want to build a more streamlined solution yourself, but this should do the trick in a pinch. See attached example.
  7. I totally feel your pain! I probably just have lowered expectatoins these days. To be honest, I wouldn't have expected this to work, simply based on past experience with different implementations of Bullet. I'm curious if the bullet SOP plugin fares any better?
  8. I guess it just comes down to which solver you choose to use. It's the old classic accuracy vs speed conundrum. I think fractured RDBs are implemented the same either way, it's just the solver that treats the data differently. Bullet is designed for games after all, so it's not too surprising that it doesn't fully sample Houdini forces across the surface of the object. Agreed, it would be better if the full limitations of the solver were documented. btw, have you tried using packed RBD objects? They make the fracturing workflow quite a lot simpler and since each piece is available as a single point in DOPs, the whole suite of POPs/SOPs tools are available to control the sim.
  9. If you're on a bugdet I wouldn't worry about a top line GPU. I run Houdini with an antique GTX 240 and have never had an issue. Houdini doesn't use my GPU for anything other than opengl draw anyways. RAM (24 Gb if you can), CPU and 1 or 2 SSDs should be your priority. On the other hand, if you like to game in your free time maybe save up for a newer GPU...
  10. There's no shame in using attribute VOPs if you prefer more of a visual programming approach. That should be quite familiar coming from c4d. See if you can recreate the solution using VOPs? Most vex functions will map directly to a node in VOPs.
  11. In this example Houdini doesn't provide you with row and column numbers of a point. You'll find Houdini to often be more DIY, but everything you've mentioned is easy to do. Remember, Houdini will typically run operations over all points as if they were a flat array, rather than per row or column or whatever. So, it's up to you to sort your data and fit your operations to it. When working with a parametric primitive like a grid, it's trivial to figure out the row and column of a point. You can display point numbers if it'll help you figure out the row and column order. Since you know the number of rows and columns and the point indices, you could do the math yourself in a wrangle SOP and store row and col into per-point attributes. Or, you could use the UV texture node, set to rows and columns mode (writing to points). Now each point has a UV (and W) value that represents the normalised row/column. If you don't want the value normalised, simply scale the UV by row and column count (-1). There are always many ways to accomplish the same task in Houdini, with the wrangle nodes being the jack of all trades! Houdini makes very few assumptions about your data, leaving you to choose the most appropriate tools for the task at hand. At this point you'll have either a hand-made attribute or a uv attribute that you can make use of with the copy SOP and staming. It's just a matter of scaling the radius values by the row/columns that you've generated.
  12. If you need extreme animated slowdowns, like bullet time, then the most reliable method may be to adjust the timescale under the advanced tab of the smoke/pyro solver, rather than the timescale of the dopnet. The obvious downside of this is that you'll have to simulate all of the frames, rather than interpolating between fewer cached frames. Also, note that not all of the microsolvers respect timescale, so you'll need to manually adjust rates according to your timescale e.g. source velocity, gas dissipate
  13. Are you doing these as pre-fracturing for a dynamics effect? You might try implementing the recursive fracturing in a SOP solver within the DOP net. That way you can decide where and when secondary fracturing should occur according to your simulation rules. You can find a few threads around here about that kind of thing.
  14. Are you talking about the SESI EC2 setup? I'm pretty sure the machine limit was more like 20 machines last time I used it. Agreed, I wouldn't rely on it for constant use or simulation, but worked well for me in a tight spot!
  15. I can't remember the last time I didn't use a microsolver on a job, but that usually just involves plugging them into the inputs of the smoke solver, not building something 100% custom from the ground up. Why re-invent the wheel (and who has the time anyway)? Clients are always wanting smoke to do some magical bullshit, so microsolvers are a necessity.
×
×
  • Create New...