Jump to content


  • Content count

  • Donations

    0.00 CAD 
  • Joined

  • Last visited

  • Days Won


char last won the day on November 23 2020

char had the most liked content!

Community Reputation

17 Good

About char

  • Rank

Personal Information

  • Name
  • Location

Recent Profile Visitors

684 profile views
  1. Rendering thin lines Mantra

    Sweet man, thanks for you reply, I suppose converting it to volume wasn't the best option to render it, the image I posted just has a lot of glow and it may have mislead me a little bit, when I tried to achieve the glowing of the edges. Hvala puno Tesan!
  2. Rendering thin lines Mantra

    Hi all, Recently I have been trying to understand a bit more about rendering. I was trying to achieve something similar with Mantra. My approach from past experience would be running a pop sim and drawing lines out of the particles to create straight trails as the picture shows. I would then volumerasterizeattributes an attribute like curveu which is ramped to control the intensity along the curve. It would essentially create a volume to render in Mantra and then use Micropolygon rendering to render the volume slightly faster than PBR. I would use a pyroshader and would wire the rasterized attribute into the temperature and density to give it some intensityand color. What I can't seem to achieve is these thin lines that are shown on the photo, I end up with a very thick individual lines in the volume regardless how low I push the pscale or how high the point count is. I assumed I needed more subdivisions to prevent the volume from stepping which solved the issue to some degree but took a tool by being a lot heavier in the scene, but I still can't get the thin lines like in the preview. Can someone explain their approach on how they would use POP's and lines to create such result as the picture shows, or just clarify that it is indeed a necessity to push the pointcount quite high and reduce the pscale in volumerasterize as low as my hardware allows. Thanks, C
  3. The Gas Wind DOP applies a wind force, adjusting the velocity field in the direction of the ambient wind direction. I'm guessing it's speed is calculated through the varying velocity in your smoke sim. I'd build my own Gas Wind field as the default one tends to be quite slow, you can build it using custom fields. Not sure what math operation is behind the node though. EDIT: just increase the value in your simulation (Gas Wind) to 2.3 let's say and see if you get any closer to the value you want.
  4. So if I understand this right, you spawn for example, piece01 on Frame 1, then you spawn piece2 on Frame 2 or any other piece. You want to connect the 2 pieces together with a glue constraints as soon as it gets spawned into the simulation?
  5. Thanks for the quick reply, seems like I the idea I had with the timeshift was quite close, I was just missing that handy detail expression you added inside the point() in the Timeshift sop. Thanks again for your help, works great!
  6. Hi all, I've been looking around for a solution to a problem I'm facing. Would it be possible to have a smoke cache which you read in from disk and stamp it on to around 10 points using the "new" for-each method instead of stamp copy. Each of the points which I am using as a destination geometry has a StartFrame attribute assigned which would define when the cache starts playing and when it is stamped on to the point. I think I'm missing a Timeshift somewhere in my network but I'm not really aware where to use it. My current take on this is using a switch node with a null as a second input and switching based on a point expression looking for the StartFrame attribute and comparing it to the current frame, once the current Frame is bigger than the attribute it switches to the first input and copies the cache onto the point. The problem is that the cache isn't offset anywhere, so it just plays whatever frame is being read from the disk for all the points even thought it's copied onto the point at random times. I've only found solutions to this problem using the copystamp which isn't really efficient nowadays. Thanks!
  7. POPs: pre solve vs post Solve

    You generally don't put microsolvers like Gas Dissipate into the post solve or pre solve in your case, as that's where the source comes in. Everything solves in a general direction which goes from LEFT to RIGHT. First a smoke object (container is created), that's your container which you will later populate with density, temperature, vel and other attributes, then you usually have a gas resize fluid dynamics which will check if density is there and how much it has to cut the bounding box to speed up the simulation (depends on how you set it up but that's the idea), third is usually velocity changes, so any microsolvers changing velocity overtime and after that you source in the volumes (that's my understanding of the Solve in DOPs). I'm not sure why in your case that is happening but I would but that dissipate in the Velocity update (always use this input for modifying things using Gas nodes) input and use Pre Solve input for the Gas Resize Fluid Dynamics (that's always been the practice, I never questioned why that is but it has to do with the order of the solve. I think best example would be if your smoke is advected, you wouldn't resize your bounding box with gas resize after being advected but before, as it wouldn't update the size accordingly I believe). If you want a really detailed explanation I'd recommend reading the documentation or wait a bit for a senior artist who knows the solver more in depth to step in and either correct me or explain further down how it works node by node.
  8. POPs: pre solve vs post Solve

    Pre-Solve Microsolvers attached to this input will run before the main solve step. For example, a SOP Solver can be used to modfiy the object’s geometry, and POP force nodes can be used to apply forces to specific objects. A good example for pre solve use is the Gas Resize Fluid Dynamics in Pyro Solver, where it resizes the container at each step. Post-Solve Microsolvers attached to this input will run after the main solve step.
  9. Before trying to replicate an effect like this, I would suggest to study how the solver works and the basics of smoke / pyro simulations. First look at your photos I'd say, most of the time if you feed the solver rubbish, rubbish will come out of the solver too, so make sure your source works well enough to produce good results. Also simulating with 10th scale might produce issues if you don't resolve the timescale correctly. Solver will try and solve the smoke the way it would work in real life, but you can't really increase the size of your source to 1 kilometre in your scene due to the performance issues you will have. You can tackle that with Timescale parameter to either slow down the simulation as that will give the impression of the smoke simulation being bigger in scale even though the scale in Houdini might just be 10x10m. Study basics first and then tackle harder things, you'll do yourself a favor. Hope this helps!
  10. Fluid Source vs Pyro Source

    I've just recently looked into understanding a bit more about this topic. Obviously in Houdini, you can achieve the same thing multiple ways. Let's say we take away the computation time of each technique, the effect will be pretty similar to another at the end, right? Houdini is being developed and optimised well enough and as an artist you want to stay on top of things when these "modern" methods like you said, come into play. So if you don't have any other reason to use old methods, I guess don't use them. Pyro Source from what I've seen and tried is a much more straight forward way in terms of how fast it computes and I find it way more intuitive. It's also cleaner to me. Workflow wise you generate points with certain attributes like density and so on, either on surface or inside a volume (different methods on Pyro source), you can then add attribute noise to these points and at last you volume rasterize these attributes into voxels which the solver can then read, but at this point I'm sure you already know most of this. I can't really elaborate on any other aspect apart from performance increase and how clean the setup using these nodes. Hope that helps.
  11. Explosion timing methods?

    I'm aware of that problem, countering it with masking and disturbance fields would probably help I assume. Is the video you provided really the only "efficient" method (I've seen it before) of actually getting that initial punch and then letting it slowly drift with drag?
  12. Explosion timing methods?

    Hi all, Going to get straight to my point here. I've been trying to wrap my head around a proper workflow for achieving good timings explosion and smoke simulations. Let's say in this example explosion , the look and the timings are great. My ideas are either having proper advection methods, using animated divergence, injecting high velocities for first few frames and then using drag to slow it down or (last idea I had today) using Time Warp node, to retime the whole explosion caches to your preferred look. Could someone experienced enough drop a few lines around what the approach of an FX artist is whilst tackling a explosion in a shot for a film or just in general. Am I going down the right path with these methods or is it completely off? Thanks
  13. growing line effects

    It's based on how fast the particle moves from it's source (velocity), so by reducing / increasing it, you can control the speed of the line moving away in your case.
  14. Rotate Particles ?

    https://vimeo.com/288890436 You can do some matrix magic and use the Orient attribute. Jump to around 30:00 for a simplified example to what you need.
  15. How could I emit pyro from particles?

    Turn the particles into fuel in order to trigger burn in your pyro sim. I think that would be done through rasterize particle SOP.