While working with python states I've recently bumped into an issue where the displayed geometry in the viewport is offsetting my hou.GeometryDrawable guides.
The values that are set on the guide geometry do not change but their position in the viewport does.
The attached gif will show the behavior.
Has anyone experienced something like this before?
Cheers!
Found 6 posts.
Search results Show results as topic list.
Technical Discussion » Offset issue with guide geometry in python states
- nex
- 62 posts
- Offline
Technical Discussion » Stopping the cooking
- nex
- 62 posts
- Offline
Yeah, I am used to HDAs cooking a bit longer due to their size, expressions, python scripts etc.
That is expected and can be optimized, but in this case, there are dops evaluating no matter what, which makes me wonder if that is preventable.
That is expected and can be optimized, but in this case, there are dops evaluating no matter what, which makes me wonder if that is preventable.
Technical Discussion » Stopping the cooking
- nex
- 62 posts
- Offline
Sorry for reviving this old thread but I recently came across this issue with the sop version of the vellum solver.
I have a vellum solver inside a subnet inside of an hda.
The subnet is bypassed and everything inside of the subnet is bypassed as well, including the vellum solver.
The display flag is not on the vellum solver and there is no output sop that would influence the cooking.
Additionally, there is no incoming geometry, simulations are deactivated and I am in manual mode.
When I create the hda, the vellum sop still gets cooked for quite a bit(1.5 seconds).
Looking further into this I realized that putting down any of the sop versions of vellum, pyro, rbd, seems to cause the dop net inside to cook, no matter what I try.
Is this behaviour expected?
(using 18.5.462)
I have a vellum solver inside a subnet inside of an hda.
The subnet is bypassed and everything inside of the subnet is bypassed as well, including the vellum solver.
The display flag is not on the vellum solver and there is no output sop that would influence the cooking.
Additionally, there is no incoming geometry, simulations are deactivated and I am in manual mode.
When I create the hda, the vellum sop still gets cooked for quite a bit(1.5 seconds).
Looking further into this I realized that putting down any of the sop versions of vellum, pyro, rbd, seems to cause the dop net inside to cook, no matter what I try.
Is this behaviour expected?
(using 18.5.462)
PDG/TOPs » Showing the TOP status icon at the container HDA node level
- nex
- 62 posts
- Offline
PDG/TOPs » Command Chain problems due to Python Script Node
- nex
- 62 posts
- Offline
Thanks Ken, that did the trick!
But let's say I would want that chain to be dynamic, what would be the solution in that case?
But let's say I would want that chain to be dynamic, what would be the solution in that case?
PDG/TOPs » Command Chain problems due to Python Script Node
- nex
- 62 posts
- Offline
Hi,
I have the problem that as soon as there is any kind of python node upstream of a command chain, it messes up the cooking process.
This happens even when the python node is not doing anything.
Did anyone have this issue before? (Tried on 17.5.327 and 17.5.350)
Cheers!
I have the problem that as soon as there is any kind of python node upstream of a command chain, it messes up the cooking process.
This happens even when the python node is not doing anything.
Did anyone have this issue before? (Tried on 17.5.327 and 17.5.350)
Cheers!
-
- Quick Links