[[Template core/front/profile/profileHeader is throwing an error. This theme may be out of date. Run the support tool in the AdminCP to restore the default theme.]]
Community Reputation
8 NeutralAbout celd
-
Rank
Peon
Personal Information
-
Name
Filip
Recent Profile Visitors
1,283 profile views
-
Hi, I wrote some code into OnLoaded event handler to run when I paste the HDA, something like this: if not hou.hipFile.isLoadingHipFile(): rebuild_prompt = hou.ui.displayMessage( "Would you like to rebuild?" , ("Rebuild", "Do not Rebuild")) It seems opening a ui dialog like this breaks the copy-pasting process and does not move the pasted node into a correct position near the cursor. I thought about manually moving the node to the cursor in the code after the dialog, but I dont think it makes sense and I cannot even access the node I am copying anyway (assume many nodes in a subnet all being copied at once) Any idea how to have a dialog that opens when HDA is being copy-pasted but in a way that doesnt stop/break the copy-pasting itself? Many thanks
-
Coronavirus must be a global pandemic! It has even infected my odforce!
-
In case anyone ever stumbles upon this thread and wonders what caused these problems, I think I solved it. Inside the gas guiding volume dop, there are 2 gas linear combination nodes for guidingsurface and guidingcollision fields. These nodes should make sure that collision fields are properly accounted for in the guiding surface field, however if your collision field is set up in static object as a "Volume Sample", it produces very stepped guiding surface in the domain of the collisions. The solution to this is to either use "Ray Intersect" on the static object and so calculate the collision field every frame, or disable the 2 gas linear combination nodes, and do the same operation in sops - using vdb combine->sdf difference, and then bring it over with a sop solver. This produces a nice smooth guiding surface and so no weird artifacts happen.
-
celd started following reference multiparm parameter into multiparm label and flip exploding around collision bound
-
Hi, I am summoning all of you flip gods! In the images you can see the flip explodes upwards for no apparent reason, this seems to happen along the boundary of the collision object. I am using guided ocean layer setup. The collisions otherwise behave correctly. I have tried high res sim, low res sim, changing grid resolution, changing collision geometry (submarine model, simple scaled sphere), deforming collision geometry, object transform collision geometry, zeroing out collisiovel field, high resolution collision vdb, low resolution vdb, playing around with depth of the guided ocean layer, different amount of substeps(both flip solver and autodop), reseeding settings, changing integrator types in the flip solver and probably more... Quite frankly I am at my wits end and I wonder if anyone has ever seen this kind of a problem and if there is a solution to it. I would also like to avoid making the boundary layer exceedingly deep, as this would most likely kill all the detail. I have attached a simplified hip file where this problem occurs. Thank you exploding_water_problem_v1.hip
-
This is exactly what you can use the new TOPs for - They give you the option to run these water simulations essentially at the same time, with caches further down the stream beginning to run as soon as their dependencies are available.
-
Hi,I have a multiparm block (list) folder with 2 parameters : 1)label and 2)integer parameter with different values for each parm instance. I would like each instance of the label to reference its pair instance of integer parameter (and then hide the integer parm so users can only see the label displaying its value). I tried writing this: `ch("intparm#")` into the label field, but it seems to always look at intparm1, even for additional instances. Is there a way to do this somehow? Maybe force a python script into the label field? Any other workarounds? Thanks
-
if you unlock the POP force node and go into the noise_force VOP, you can see on the right how it combines the force every frame, there are two bind nodes: one to bring the force into the vop, and second to output it. Between them there is an add node and it combines the force with a calculation from the current frame. If you want to kill the additional force you are adding on one axis, you could drop down multiply node and multiply it with a constant vector - for example (1,1,0), that way it will only add the force on x and y axis.
-
How to move point (particles ) back to their origin place and shape
celd replied to Gabriel_Wolf's topic in General Houdini Questions
Oh are you just trying to retime the simulation? in that case you can just delete the expression in the timeshift (after transformpieces) and keyframe your own values, so for example on fr. 1 you set it to 120 and on fr 120 you set it to 1, then it will run it backwards according to that animation. -
How to move point (particles ) back to their origin place and shape
celd replied to Gabriel_Wolf's topic in General Houdini Questions
The first and third input into your transformpieces is your fractured + packed geometry. Instead, the third input should be the same as the second one, except before you connect it, you also need to drop timeshift and set it to a static frame. It wont fall down if you dont add gravity? Seems to me like your sim is already really broken up by the wind anyway -
How to move point (particles ) back to their origin place and shape
celd replied to Gabriel_Wolf's topic in General Houdini Questions
Looks to me like you basically set it up correctly, but last input for transformpieces should also be the point representation coming from dop, with timeshift on the rest frame. Also why not do an proper bullet sim with pop wind plugged in? -
You can volume sample the fields and replicate the same setup that pyro shader has. You can do this in the shader as well. color_attribute_transfer.hip
- 4 replies
-
- color
- color voxel
-
(and 1 more)
Tagged with:
-
I would say it depends on the studio, usually the larger studios should have plenty of space to spare. If you are however really starved for space I dont see why you couldnt do it, just be careful when compressing vector fields like this, I found it can remove too much information sometimes.
-
Think of it as comparing an 8bit jpg and 32bit exr formats, they capture different ranges of data but can display the same thing. 16 bit volume will have a smaller range but still look correct enough under the right conditions. So its the bit depth of the value of individual voxels.
-
You havent provided the source geometry so people cannot really help you. I would however suggest you use vellum for this, instead of the old cloth solver, it was never very good.