nuki

hey, thanks for your links! After some digging through what NASA has to offer I think I will either go with using their HORIZONS system (super accurate but I'd have to fetch and store a ton of data in a LUT) or the Keplerian approximation using the specified variables (continuous and I dont need to get into telnet).

sure - would be great if you're willing to share! in case you remember any resources you used that'd be helpful too. fyi - just found this

Doing some shots of planet earth where I'd like to have plausible transformations for the sun, moon, earth (ideally including its axis wobble) and star-backdrop (rotation only) relative to each other. Since there's different models in respect to their origin and accuracy the matter is a bit confusing for me to untangle. Hence I was hoping someone here might have attempted something similar and could point me to a comprehensive resource. In the end I'd like to have a float slider to adjust datetime driving an approximation of the mentioned celestial bodies' transformations.

hey @Nemiko, you could use the inverse of @nage (normalized age, going 0-1 from birth to death - equivalent to @life/@age) as a damping factor on @v. In the example file, you can adjust the profile of the damping/stopping effect with a ramp parameter. To stop the wind from acting on deactivated points I just put them in a group and exclude it on the popforce parameters. I adjusted the max lifetime (which is in seconds) of the particles to make values easier to pin down with the ramp, but you could also fit(val, min_val, max_val, 0, 1) the value into 0-1 range before running it through the ramp instead to prevent particles from dying. deceleration.hiplc

#1 should just be a visualization problem. if you rasterize multiple attributes you'll have to tell houdini how to visualize them and it looks a lot like it's also visualizing some vector field (which visually only appears where values are above 0). Use a volumevisualization sop to define the visualization. And/Or a PyroPostProcess after your combustion sim. #2 can just be the viewport clamping your volume display. hit d in the viewport, navigate to the Texture tab and raise/untick the 3d texture 'limit resolution' parameter. Unless you're worried about the 'naked' flames in which case you can check the @flame value of your source there and adjust the smoke emit range in the pyro solver accordingly.

hey there @immeen, I did gray-scott diffusion in a course some time ago - set it up with 2d volumes (for the reacting 'chemicals' A and B), but the same logic applies to polygons too, just use connectivity instead of the voxel neighbourhood. Its a 2d solve, but you could string together slices of timesteps of this diffusion to create 3d shapes like this. To change the effect all you have to do is initialize the ca and cb volumes differently and play around with the parameters on the solver. reaction_diffusion.hiplc

See, temperature is just a scalar field. So it gets remapped to kelvin with reference temp as a multiplyer. So if temperature = 1.0, then kelvin = reference temp * 1.0 Ambient temp on the other hand specifies how many kelvins a temperature value of 0 assumes, so I guess its an additive offset. theres an explanation in the docs as well

Ambient temp = the sourrounding medias temperature Reference temp = whatever temperature @ 1.0 gets remapped to (flame temperature) if Ambient temp>reference temp the smoke will not rise but sink (like dry ice fog). More info.

thanks for the explanation atom. Guess I misunderstood the application for point vdbs, although they seem very useful for exchanging pc data. no more baking sims to joints i guess!

you can advect packed geo with the vel field of a pyro sim.

stumbled upon point vdbs while doing some volume deformation stuff. the ability to convert voxels to points and back again would be very handy in that usecase. So, is it possible to - convert a point vdb (eg. representing voxel centers) to a fog vdb and vice versa? - access individual vdb points (eg. in a volumewrangle) for transformation/lookup/... without unpacking? this can all be done with a wrangle for point creation/deformation and volumerasterizeparticles. but since vdbpoints are apparently also stored in a grid they would inherently be a great intermediate "lattice" for volume deformations (and the inevitable interpolation required). But maybe I just misunderstand the usecase for vdb points (pc compression, rendering, ....?).

cool stuff!

think its just called 'expansion' in sparse pyro. not sure if it behaves exactly the same - both add to divergence so probably similar.

just tested your file and i dont see any issues? I mean, it runs - there it a typo on the dopnet geo, so it doesnt merge in anything. Also it has display and template flags both set. But if you exchange "Wall" with "Ball" it seems to work fine. if you have a problem with the way it behaves could you specify a bit what its supposed to do? EmitRBD2.hiplc

hey mauro! first you'd have to set up an attribute to drive the shading. I just used a float attrib called heat and used the 'myscale' variable you set inside the dynamic scaling geo wrangle. As you run the sim, whenever the enablesolver fires the scale values are added to this heat var, collecting it over time. For the heat decay you'll just need another geowrangle that dampens this heat attrib every time step. I put it before the dynamic scaling part so the newly added values dont get reduced immediately and they can fully reach 1.0. Then you have a prim attrib on your packed geo which you can visualize with a color sop. To access the heat attribute inside any shader you can use a render state vop with packed:heat as a value name. Then you can plug this float value into a ramp parameter and give it some color, emission...! LiveScalingBulletsSetup02.hiplc