Search the Community
Showing results for tags 'bugs'.
Found 4 results
-
Hello! I am trying to implement python expressin in Object Merge node in parm "objectpath1" to get geometry from connected nodes to parent geo. So as final result if you connect/disconnect first input of test node geometry should switch to another one. Actually script working fine and storke of parm updating if i connect or disconect ANIM node, but object merge node do not updating geometry while i turn on/off "Enable Merge" toggle on object merge node. It's seems node just not cooking properly. Any suggestions how to solve this problem? Or maybe hscrip variant? P.S. check test setup in hip uploaded switch.hipnc
-
Hello guys !!! Anybody have similar problems with context menus ? The same problem I have on all version and builds in past. OS - centos 7 GPU - nvidia 1080 Ti, 390.67 driver
-
I'm trying to source particle emitters from geometry that i created in a scene. Unfortunately, there seems to be an issue with the popsolver node, it's saying that: 'Connection 2 input is the wrong type' I'm trying to create a whisp effect, following some tutorials but already stuck and not able to continue. Please help! WhispIssue.hipnc
-
I am new to houdini (but not vfx) and I believe this is a bug. I'd appreciate a more experienced user's verification. After entering a number manually into the spreadsheet, the translate handle is no longer at the same position as the vertex. Each time I move the handle, the vertex moves farther away from the handle, no matter which direction the handle is moved, in an accumulating error. After then selecting a new vertex, moving the handle still makes this "accumulating error" appear in the original vertex. Please try the following simple example, and see if you have the same results: 1: With the geom spreadsheet ("gs") open in a pane, put down a cube, dive in; 2: select vertex #7 (-0.5,0.5,0.5) interactively in viewport, so it's handle appears, and an edit node is added (it really doesn't matter which vertex) 3: In the geo spreadsheet, change point 7's x coord from -0.5 to -0.1 (by manually entering "-0.1" in the appropriate cell). You'll notice the value of the cell will change to "0.3" - not 0.1 as expected. (notice that it has changed by twice the appropriate amount - should have moved +0.4, actually moved +0.8) 4: At this point, notice that the handle is now offset from the vertex. If you move the handle, the phenomenon I mentioned above will occur (the point just moves further in the X direction from the handle each time the handle is moved, no matter which direction, or transform). 5: select a different point (perhaps point 4), and translate it with it's handle. Notice that point 7's x value is changing upon each move of the handle still. If you start again, only executing steps 1-3 above, (eg change the x coord from -0.5 to -0.1 in the spreadsheet, making the cell read 0.3) then press ctl-z, you will notice that instead of the gs updating to "-0.5" as expected, it updates to "-0.1", only half way back to it's original position. Although the handle is still misaligned to the vertex, the "accumulating error" doesn't happen when moving the handle. Perhaps when the geo spreadsheet value is changed, the point position is updated twice and the handle position not updated, instead of updating the point position and the handle position? Before submitting this, I searched for similar posts here, but found very little. One post mentioned that the geo spreadsheet was for "looking, but not touching". I can't believe this is the author's intentions, because if it were, the cells should always be locked. I would think the gs would be a great way to make easy creative tweaks on initial geometry, or make sure points are aligned numerically, match on-set survey points etc. BTW - 15.5.596 non-commercial version. Also the same behavior on a couple of earlier versions as well. Thanks for your time.
