nuki

hey, afair this thread had suggestions utilizing qLib to efficiently separate capture/deform for multiple pieces. the pointdeform should also be able to utilize a piece attribute out of the box tho.

ah ffs, Ce has to be a vector, then it works as intended.

i just want to accumulate a value via for loop inside a materialbuilder/inline vop. it seems super basic but i can't get it to work. inline_for_loop.hipnc

you could just clamp or min(scale_var, max_value) the scale value you calculate from @age

thats cool, didnt see the files! he's using the HORIZONS system, which is very accurate but needs data to be cached and interpolated, or fetched over the internet (which may cause issues on a farm). I implemented the less accurate, continuous offline version with the keplerian formulae. Was very interesting diving into this - looking up to the stars at night has become a lot more exciting to me for sure! Btw, for the stars there's a neat recent post on Erwan Leroy's blog!

hey tesan, cool stuff! judging from the twitter it seems to be a gravity based simulation? I've actually spent a few weeks on this and implemented the approximation formula nasa provided so generously. Also extended it by transformations into ecliptic/equatorial/geostationary coords, axial rotation and satellites. Evaluating its accuracy probably took longer than writing all of it, also because it was more fun ^^. You can watch events like eg. the transit of mercury on 01/11/1605, a mars close approach 13/07/2065, solar ecplises, regressions....most stuff is accurate to within one degree (in 3000bc-3000ad), although the moon is more like 1.5 (didnt do any of its perturbations - yet). Here's some screenshots - will update this post as soon as I get around publishing it. my workstation decided to die and is holding the latest version hostage atm... note: for the visualization I had to flatten pscale and P a bit - the real dimensions are quite insane (eg. earth, moon and iss would appear to be a single dot). The sim is in AU with 64 bit P and time, so internally everything is calculated properly.

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!