aghourab

Where's a like button when you need it...

Cheers for the speed up help. Its a shame I cannot import individual points, as that would allow me to circumvent the use of the inline CPP which I am not yet familiar with. I was surprised to find the dictionary ordered. I understand that inherently they have no order, so I was going to use a sort method, but it seemed to work. It all cooks now, but its the kind of thing where, as you mentioned, is so flakey it will most likely cause issues in the long run. I'll have a look at the inline cpp, and see if I can get it working. Thanks for the help Graham!

Its only natural that changing the resolution will affect the sim. Say you increase the resolution by a scale of two, the one voxel you had previously was an average of the 4 voxels you now have. These 4 voxels may have different densities/velocities than the averaged voxel you had at a lower resolution. How dramatic a change in the sim depends on your source and dop setup. Difficult to tell without a file. I imagine the change wouldn't be very dramatic if you had a low resolution source. Like Arrev mentioned, use the upres solver to avoid similar issues. From left to right a)High res source, Hi res sim b)hi sim, low sourse c)low sim, low source d) low sim, hi source. Ive attached a file that demonstrates this. smokeResTest.hipnc

India and China? The movies don't appear to be making any less (John Carter being the bloated exception here), and with tax credits and the expansion of several major studios into developing nations, the costs must be falling. Why then all the turbulence?

A little problem that has been bugging me over the weekend is point sorting in a python sop. I'm aware that this functionality doesn't currently exist, but I have managed to create a hack that allows me to do so. The problem at the moment is that it can be quite slow. 2 seconds per 1000 points to be precise, which hurts a little (or a lot of you need it to cook every frame, doh!). My current implementation is to create a dictionary of {points : attributeToSortTo}, delete all points, then merge in points in the correct order from a second input. It appears I cannot merge in individual points, so I'm forced to use geo.merge() in combination with a blast sop (i promote the point number i'm interested, blast all non selected, then merge it in). I'm wondering if there's a method to import individual points, or failing that, some speed tips! Attached scene file and otl for python sop. sortFromAttrib.zip

Its really a matter of your setup. There is no magical way to speed things up. But there are some tricks to get the overall process out the door quicker. For starters make your lowres lower. You want to dial it down to the point where its simply the abstract of your intended final result. Don't worry about details at this point, you can get these back later in the upres, so long as the overall motion, and volume are what you intend. I also usually unlock the solver and copy disturbance to the upres solver just to add some extra details. Clustering is always more difficult with smoke than it is with fire because smoke is slower, lasts longer, and encompasses a greater region. If you do go the clustering root, try clustering in the XZ plane, and not Y (unless of course you have a lot of vertical distribution). This allows smoke to build up naturally as it travels up, and reduces the overall scale of the containers you work with. Is resizing working for you? That can also save a lot of time. Turning down substeps (this may cause artifacts, but you can worry about that latter when you want to do a finalish sim). In the solver there are different advection systems to choose from (Advanced -> Advection). The default Modified MacCormack is actually the most accurate. But changing it to single stage may be quicker AFAIK. Change Advection method to single step as well and see how that works for you. This will take away from the sharpness and accuracy of your sim, but if its speed you want...

و مالو لو ليلة تهنا بعيد... و سبنا كل الناس أنا يا حبيبي حاسس بحب جديد... ماليني ده الإحساس و انا هنا جنبي أغلي الناس... أنا جنبي أحلي الناس

Awesome work. Must have had a fun time wrapping your head round the SH maths:p

Thanks go to Kuba Roth for pointing the following out... Jump into your shader -> Surface Model (this must be unlocked) -> on the direct lighting vop untick "enable shadows"

Not quite sure what you're aiming for here but... If you send an object with UV's to DOPs, the external faces will maintain their UV positions correctly. I.e. Sim a box RBD fracture object, with UVs and a checkerboard pattern on it, once it fractures all the faces that once belonged to the outside of the box will maintain their texture. The points on the insider will have UV's of <<0,0,0>>. If you want to isolate the inside faces based on UV's, you could simply use a compare statement (if UV == 0, then its an inside face, otherwise its outside), though I'm sure there's probably a far more elegant solution (seperate faces in sops based on UV/Normal/other attrib, then simply set different materials for the different grps). I did a quick test, and as I can't upload it i'll just quickly describe the process. After your DOP Import in your sop network>> -Attribute promote (name uv, original class Vertex, new class Point) -Lay down a vop sop -Inside, lay down Import Attribute (Attribute uv) -Feed output of the former node into first input of compare statement -Lay down switch statement, feed output of compare statement into first input of switch -Feed Global CD into second input -Feed custom Parameter into third input -Connect result into CD global output Now if you modify the custom parameter from the third input, say make it red, you should find that the inside faces are red, and the outside are whatever they originally were. VOP sops are pretty similar to shader's so you should be able to modify this to work in a shader, except that instead of connecting a custom color, you connect a anti aliased noise or something. Hope this helps...

Hmm missing file! Just a silly guess, but you sure its not a memory issue due to caching?

Stretch/Blur your source. Sub-stepping is pretty expensive. By blur, I mean trail your source so that the tail covers just over the region of the gap (and the tail perhaps contributes less fuel). Gets rid of gaps with no extra processing costs.

Had the same problem once. Its not really scene scale more so as the settings of your solver. I did a test once where I increased the scene scale some 12 times, and while I did notice some marginal improvement (maybe placebo?) it really came down to the solver settings. Have a look at the Bunkers response on the "Large Scale Explosion" thread. Some tips, play with advection speed time scales (effectively slowing down the sim), burn rate (some noise, giving natural burst like appearance), turbulence (Slow frequency offset, lower scale, gives the appearance of large scale sim. Turn this on and off to see what it looks like). No diffusion (tis your enemy, at-least from personal experience). Change advection type to BFECC (better results, less smudging). Perhaps post a file/video so people can have a look to see what your aiming for. Also, close up smoke is not fun:p (Render times?)

Heya Misterbil. You need to use the RBD Fracture/Glue object, instead of RBD, as they allow you to filter objects based on their group membership and simulate them as separate objects!

Interesting stuff:) Thanks for the share!