Bug reported as #144524

Simple technique, use a sop solver in dops to add a bit of velocity to a flip sim...

In v19.5 I can see the effect whilst inside the sop solver, this is what I'm used to.

In v20.0 I don't get the same update, I have to jump up to the dop level to see the effect.

In v20.5 I can see the effect whilst inside the sop solver again, but, when I jump up to the dop level it behaves as if the simulation is disabled. I need to go up again out of the dop network to get it to work again.

Before I submit a bug report about the behaviour in 20.5 I wanted to see if it rang any bells here first?


cheers,

A.

Ideally I want the option to have the same behaviour/orientation in "Hide other objects" as "Show all" or "Ghost Other Objects".

It's RFE 139726 if anyone wants to add to it...

When inside a rotated geo node (like you would be if modelling) with the viewport set to "hide other objects" (so you can see what you're doing) camera tumbling goes into some weird local space thing, completely throwing off the normal camera behaviour. At object level I move my mouse left / right and the camera orbits left / right... Normal behaviour. Inside a rotated object I move my mouse left / right and the camera now orbits up and down. Physically nauseating behaviour.

I can see how orienting the camera to the local space of the object may be useful, but why can't camera movement be preserved.

I did put a feature request in for it but I'm not exactly hopeful.


cheers, and happy Friday!

Andi.

Sorry but I find it both harder to find stuff, and some things like attribute data MUCH harder to read. I have to CTRL+= to zoom it up then drag the window wider to expose everything again... every single time I open the window pane. It's beginning to grate somewhat. Also why add the visualizer button when you could already just click the attribute itself to visualize it.


A.

That I could see but would op:/blah/blah work in a RS_TEXTURE node? Is that the idea in future? I'm fairly sure I read some blurb about it that said for karma.

I can see how USD is important for large studios with multiple departments, but I dare say there are many setups that will never go near USD. My concern is that more and more will need to be piped through Solaris, Karma being the prime example. It feels awkward and annoying to have to pipe my conventional job through an extra layer of complexity just to use Karma, so I'm still using Redshift.

The impetus to ask the question is Copenicus, very cool but is it going to be fully integrated or will I need to pay the Solaris tax? Same question goes for the future of Houdini in a broader sense.... will more than just Karma be locked out for non Solaris setups?


cheers,

A.

The node you're using to export the proxy needs to have it's display flag on. I've run into this before.

Hi all,

I'm doing a simplified "falling pebbles" simulation, using packed cubes as rigid bodies through a pop source, then using @instancefile after the sim to replace the cubes with rocks... Works a treat, but rotations (or display of) are a bit screwy.

Using @orient to randomise the rotation of the cubes before simulation, the simulation and dopimport stage seem to display rotation slightly off, bit when I copy to points the original master cube after the dopimport to check rotations it looks correct.

Going a different route and using a randomised @N and @up the sim and dopimport match the initial setup visually, but the copies now won't match their rotation to the incoming data... Unless I unpack first in which case I obviously get 8 cubes for each input.

Is the display thing with @orient a known gotcha? (not known by me obvs). And How would I go about making the @N & @up route match at the end?

cheers,

A.

Hi all,

I've noticed an object that gets it animation from a constraint (path in this case) affects flip much more than a simple object level animation doing the same move.

I'm assuming the object and sop level animations are correct as they match, and the constrained one is wrong. I know constraints are a bit different in H, should I steer clear of using them in cases like this?


cheers,

A

EDIT:

I've actually got this the wrong way round... The sop level animation is the odd one.

Ok...

good news/
so with a bit of judicious butchery of other peoples hip files I've managed to cobble something together that works.

bad news/
I've almost no idea what it's actually doing.

Here's my very patchy theory...

scalarfield1 just says here have a scalarfield called pump, it has no size or values yet.
sopsolver1 merges in the pump object again and does something with some data.
gasresizefield1 takes the pump field and makes it the size of the pump object.
the source node just puts values into the vel and pump fields.

One thing I don't get is how the sop solver is generating the "size" data. There's nothing I can see that links the size of the pump object to the data called size.

any info to help me out would be great,

cheers,

A.

Hi all,

Pumps! world of pain. Just trying to pump some flip about. The shelf tool either error, or if they don't the result is that the fluid (the particles you see inside the dop) just vanish on frame 2.

I'm using a flip tank rather than emitting from an object. I've set up a pump object in sops, with 2 voxel grids using rasterize attributes, a scalar one called pump set to 1 and a vector one called v set to 0,1,0. I use volume source in dops to import them, source field v, target field vel, and source field pump, target field pump.

Pretty please how do I set up a pump manually to work with a flip tank?


I should mention I can do it in Houdini 17.5 just not later versions, and a hip that works in 17.5 is broken in 19.5.

cheers,

A.

Hi Faitel,

thanks for this, managed to get it working. Cheeky to ask, but I don't suppose theres an option to get an hda rather than an hdalc?



cheers,

A.

Very kind Faitel,

I get this when trying to generate 16k textures though. That last line sounds impressive.




Traceback (most recent call last):
File "Sop/mapbox_on_steroids::1.0/refresh", line 1, in <module>
File "Sop/mapbox_on_steroids::1.0, PythonModule", line 157, in update
File "Sop/mapbox_on_steroids::1.0, PythonModule", line 303, in refresh
File "Sop/mapbox_on_steroids::1.0, PythonModule", line 129, in tiler
File "Sop/mapbox_on_steroids::1.0, PythonModule", line 32, in cropmap
File "C:\PROGRA~1\SIDEEF~1\HOUDIN~1.657\python27\lib\site-packages\PIL\Image.py", line 1167, in crop
return self._new(self._crop(self.im, box))
File "C:\PROGRA~1\SIDEEF~1\HOUDIN~1.657\python27\lib\site-packages\PIL\Image.py", line 1185, in _crop
_decompression_bomb_check(absolute_values)
File "C:\PROGRA~1\SIDEEF~1\HOUDIN~1.657\python27\lib\site-packages\PIL\Image.py", line 2728, in _decompression_bomb_check
"could be decompression bomb DOS attack." % (pixels, 2 * MAX_IMAGE_PIXELS)
DecompressionBombError: Image size (268435456 pixels) exceeds limit of 178956970 pixels, could be decompression bomb DOS attack.




cheers,

A>

Anyone have an up to date solution, (for which many of us would pay), to the issue of labs mapbox resolution? Mapbox on steroids was great but won't work with newer versions. Foolish I know but It's reasonably important in the pipeline for one of my projects....


Happy Friday!

Andi.

9 times out of 10 the answer to my questions have been pointed out in the documentation. However...

Quite often I want drive a parameter with an attribute, good example being painting a point attribute to drive the height on a mountain sop, which you can do by naming the incoming point attribute @height. It isn't mentioned in the docs at all as far as I can see but why this works becomes clear if you dive inside the mountain sop attribvop and find a bind that imports @height, and I can also see all the other things that are bound in which is helpful.

Now I want to drive the wire radius on a polywire sop, again nothing in the docs in mere mortal language, but some forum searching and ah! I can just stick an @myfloatval in the wire radius channel.

Is all this information in the docs in a way I just can't see? Do I just need to rtfm properly?

Yes I can see this on the polywire sheet:

The four numerical parameters support all the local variables of the Point operation, plus the LSYSTEM specific variables of $WIDTH, $SEGS, $DIV, $LAGE, $GEN, and $ARC.

To some degree it's gobbledegook, and I see more than 4 numerical parameters so which 4 does it mean, and my only experience of local variables is in wrangles where I can see how to tie them to incoming point attributes.

I really want to learn but I feel like I'm staggering around in the fog!

Hi Tomas,

I used a sop solver to group some points and set the mask attr, then under the pop wind used the multiply wrangle, works a treat. Much to experiment with still.



cheers,

A.

Hi,

I'm trying to get more art direction into some flip sims and I want to mask or blend off the effects of things like gravity, pop forces etc. I've managed to hook up mask field to a sop sdf to affect gravity, but things like pop wind won't work in that instance.

I tried a solver sop multiplying the popwind amplitude by the length of the velocity and again it does something but I've not found a way of visualizing exactly what that's doing.

Any suggestions as to how people localise forces or effects in dops, or visualise those things would be cool.

cheers,

A.

Sadly not, also present in 19.0.498. It's not getting in the way really but it's slightly unnerving.