> On Windows the Network editor just gets slower and slower the more you work with it.
… that sounds like a different thing than:
> it'll be fine for about 5 seconds, then all of suddend it'll pause and jump.
… I wonder if we are talking about two unrelated observations here?
I have been using H16 a lot on Windows and so far have not yet experienced any significant slowdown EXCEPT when simulations or cookings/bakings were running (some of which I could not stop but had to wait to end). That's why I suggested trying to deactivate simulations, but that does not seem to help the stutter-thing.
Marc
Found 590 posts.
Search results Show results as topic list.
Technical Discussion » Laggy UI?
- malbrecht
- 806 posts
- Offline
Technical Discussion » Laggy UI?
- malbrecht
- 806 posts
- Offline
> UI is laggy due to pyQT crap, it happens to every app that gets customization through python.
if that was the case, I would a) suspect EVERY app that “gets customization through Python” (just like you claim) to show the same behavior, which does not seem to be the case and b) I would expect the same misbehavior of modo and Houdini on EVERY computer, which definitely isn't the case.
Don't get me wrong - I don't like anything about the Qt look and feel and I was one of those who told the modo devs that switching the GUI system to Qt would create, at the end of the day, MORE problems instead of solving them. But to actually blame a specific behavior on pyQt or whatever needs some backing up and should be reproducible.
In this case (maybe in these cases, they don't seem reliably related to me) it *feels* (to me) more like a specific system issue. My shots in the dark were attempts to narrow down on the actual cause, but I admit, without a lucky strike that's probably a waste of time.
A virtual machine on that system mimicing the same setup might be another test to see if it is a hardware problem - but that, too, seems overkill.
Sorry.
Marc
if that was the case, I would a) suspect EVERY app that “gets customization through Python” (just like you claim) to show the same behavior, which does not seem to be the case and b) I would expect the same misbehavior of modo and Houdini on EVERY computer, which definitely isn't the case.
Don't get me wrong - I don't like anything about the Qt look and feel and I was one of those who told the modo devs that switching the GUI system to Qt would create, at the end of the day, MORE problems instead of solving them. But to actually blame a specific behavior on pyQt or whatever needs some backing up and should be reproducible.
In this case (maybe in these cases, they don't seem reliably related to me) it *feels* (to me) more like a specific system issue. My shots in the dark were attempts to narrow down on the actual cause, but I admit, without a lucky strike that's probably a waste of time.
A virtual machine on that system mimicing the same setup might be another test to see if it is a hardware problem - but that, too, seems overkill.
Sorry.
Marc
Technical Discussion » Laggy UI?
- malbrecht
- 806 posts
- Offline
Houdini and modo … hmm … could be a single-core issue (but I would expect Blender to suffer from hickups then as well) or an openGL thing.
Have you, maybe, increased GPU recovery time? Try setting that to default. Some tools that leverage GPU for calculations suggest doing that, but it can lead to strange “stuttering” in applications that use openGL.
Marc
Have you, maybe, increased GPU recovery time? Try setting that to default. Some tools that leverage GPU for calculations suggest doing that, but it can lead to strange “stuttering” in applications that use openGL.
Marc
Technical Discussion » Laggy UI?
- malbrecht
- 806 posts
- Offline
Have you checked the CPU usage? On Windows you can use the Resource monitor and have a quite convenient overview on what is draining how many cycles … maybe you can spot something there.
Also, maybe you have some software installed that interfers with H - try setting up another user account and run H there.
Marc
Also, maybe you have some software installed that interfers with H - try setting up another user account and run H there.
Marc
Technical Discussion » Laggy UI?
- malbrecht
- 806 posts
- Offline
Are you using the latest version of H16? And - have you tried deactivating simulations (bottom right of screen, the “cloud” symbol, set it to strike-through), just to check if there isn't some wild goose simulation running for whatever reason …?
Sorry, just wild guessing here …
Marc
Sorry, just wild guessing here …
Marc
Houdini Indie and Apprentice » Can't find the new Auto Rig Shelf
- malbrecht
- 806 posts
- Offline
Moin,
using the search function in this forum, you can stumble about this topic popping up a couple of times :-) https://www.sidefx.com/forum/topic/47786/?page=10#post-217898 [sidefx.com]
But I am sure SideFX will add a shelf tool or pane to the major tool shelf soon, once the (already documented, as it seems) quadrupediae are online.
Marc
using the search function in this forum, you can stumble about this topic popping up a couple of times :-) https://www.sidefx.com/forum/topic/47786/?page=10#post-217898 [sidefx.com]
But I am sure SideFX will add a shelf tool or pane to the major tool shelf soon, once the (already documented, as it seems) quadrupediae are online.
Marc
Technical Discussion » Need help on python scripting ( Real-time viewport recorder)
- malbrecht
- 806 posts
- Offline
> I mean is that every time I select a node my object merge path changes. Is there anyway to do that?
Not sure how this is meant … there is a “get selected node” feature in the Python API (I am not familiar enough with that to tell offhand how it's named), so you could have a Python node question the currently selected object and, e.g., capture position data from that into an array as scribbled above.
But … I am not sure if that is what you're after …
Marc
Not sure how this is meant … there is a “get selected node” feature in the Python API (I am not familiar enough with that to tell offhand how it's named), so you could have a Python node question the currently selected object and, e.g., capture position data from that into an array as scribbled above.
But … I am not sure if that is what you're after …
Marc
Technical Discussion » Need help on python scripting ( Real-time viewport recorder)
- malbrecht
- 806 posts
- Offline
Hi, Alireza,
I am not sure I can follow …
The way I understand your task is this:
- you have an item (Null, geometry, whatever)
- that item has an initial XFO
- you want to transform that item over time
- and store that (ongoing) transformation sampled by frames on the timeline
If that is correct, then capturing the transform into auto-keyframes is the easiest way.
If you *want* to use a Python node to capture the data into an array, what I would do is object-merge the (moving) geometry node into your “scripting node”, set its import options to “transform into this item” (this way you get global positions instead of local) and connect the output of the merge node to your script node.
Inside the script node you then can access the point attribute from that input (for position) or address the merge node through Houdini's Python API. Something along this idea:
That's the current position (as the variable name suggests), now if you create an array on frame 1 (checking current frame) and only add the current position indexed to its frame into that array (only initializing the array on Frame 1), you get a “history of transforms”. Since Python nodes remain in memory, that array is a global variable.
The more elegant way, as pointed out above, is to check if the array exists yet and initialize it if not (that way the node can get baked fresh even if it is not at frame 1).
This gets executed/evaluated ONCE each frame, so there cannot be any lockup. If you need a higher resolution than 1/frame, you may have to increase the subframe count, but the tech will still be the same.
The question remains why recording that data to keyframes isn't sufficient - if you don't want to use the captured data to manipulate other channels right away (which was what I did, and that does not work very well in Houdini).
Marc
I am not sure I can follow …
The way I understand your task is this:
- you have an item (Null, geometry, whatever)
- that item has an initial XFO
- you want to transform that item over time
- and store that (ongoing) transformation sampled by frames on the timeline
If that is correct, then capturing the transform into auto-keyframes is the easiest way.
If you *want* to use a Python node to capture the data into an array, what I would do is object-merge the (moving) geometry node into your “scripting node”, set its import options to “transform into this item” (this way you get global positions instead of local) and connect the output of the merge node to your script node.
Inside the script node you then can access the point attribute from that input (for position) or address the merge node through Houdini's Python API. Something along this idea:
currentposition = hou.Vector3(node.parm('whatever_your_geo_node/tx').eval(),node.parm('whatever_your_geo_node/ty').eval(),node.parm('whatever_your_geo_node/tz').eval()) # create Vector3 from node's transform parameter channels
That's the current position (as the variable name suggests), now if you create an array on frame 1 (checking current frame) and only add the current position indexed to its frame into that array (only initializing the array on Frame 1), you get a “history of transforms”. Since Python nodes remain in memory, that array is a global variable.
The more elegant way, as pointed out above, is to check if the array exists yet and initialize it if not (that way the node can get baked fresh even if it is not at frame 1).
This gets executed/evaluated ONCE each frame, so there cannot be any lockup. If you need a higher resolution than 1/frame, you may have to increase the subframe count, but the tech will still be the same.
The question remains why recording that data to keyframes isn't sufficient - if you don't want to use the captured data to manipulate other channels right away (which was what I did, and that does not work very well in Houdini).
Marc
Houdini Learning Materials » I can't use help documents
- malbrecht
- 806 posts
- Offline
Moin,
please keep reporting this (and everything else around docs) - the socket thing “catnip” just mentioned is something I have reported twice at least (including bug reports), it happens frequently here. It was supposed to have been fixed, but keeps popping up.
As far as I can see, it is only a “debug report”, informing the developer that a connection was prematurely ended by one of the parties, something that in networking happens all the time, so this message should not be published to the user, I think.
Marc
please keep reporting this (and everything else around docs) - the socket thing “catnip” just mentioned is something I have reported twice at least (including bug reports), it happens frequently here. It was supposed to have been fixed, but keeps popping up.
As far as I can see, it is only a “debug report”, informing the developer that a connection was prematurely ended by one of the parties, something that in networking happens all the time, so this message should not be published to the user, I think.
Marc
Technical Discussion » Installing Houdini 16 (Indie)
- malbrecht
- 806 posts
- Offline
Have you tried resetting your password?
http://license.sidefx.com/reset_password.php [license.sidefx.com]
Obviously something with your login credentials isn't working.
Marc
http://license.sidefx.com/reset_password.php [license.sidefx.com]
Obviously something with your login credentials isn't working.
Marc
Edited by malbrecht - March 5, 2017 14:33:53
Technical Discussion » Installing Houdini 16 (Indie)
- malbrecht
- 806 posts
- Offline
Moin, anonymous,
> Should i un-check the commercial License Server?
no, because “Indie” is a commercial license (which is clearly stated by the EULA, which you probably read).
> What for are those HQueue Client and Server?
Have you tried the docs?
http://www.sidefx.com/ja/docs/houdini/ref/hqueue [sidefx.com] (tldr: Render management).
As for your other issue (second thread): If you are on Windows, try running the License Tool as Administrator to install your licenses. If automatic installation does not work, try a manual installation, download a license file from http://license.sidefx.com/login.php, [license.sidefx.com] save it to your HD, open it, copy the content to your clipboard and paste that into the License Tool “Enter license manually” input field.
Marc
> Should i un-check the commercial License Server?
no, because “Indie” is a commercial license (which is clearly stated by the EULA, which you probably read).
> What for are those HQueue Client and Server?
Have you tried the docs?
http://www.sidefx.com/ja/docs/houdini/ref/hqueue [sidefx.com] (tldr: Render management).
As for your other issue (second thread): If you are on Windows, try running the License Tool as Administrator to install your licenses. If automatic installation does not work, try a manual installation, download a license file from http://license.sidefx.com/login.php, [license.sidefx.com] save it to your HD, open it, copy the content to your clipboard and paste that into the License Tool “Enter license manually” input field.
Marc
Technical Discussion » 3D Mouse and camera/view pivot
- malbrecht
- 806 posts
- Offline
> I'd like to try but I'm on H15, maybe wait for updated drivers by 3Dconnexion ?
3d Mouse support is not available in Houdini 15, only in Houdini 16.
As for the horizon lock: File an RFE - the more people want changes to the implementation, the more likely it is that E. has another go at it.
Marc
3d Mouse support is not available in Houdini 15, only in Houdini 16.
As for the horizon lock: File an RFE - the more people want changes to the implementation, the more likely it is that E. has another go at it.
Marc
Technical Discussion » 3D Mouse and camera/view pivot
- malbrecht
- 806 posts
- Offline
Moin, Jonathan,
to lock the horizon you can disable the tilt channel. I think that is exactly what modo is doing: Ignore that single channel.
Marc
to lock the horizon you can disable the tilt channel. I think that is exactly what modo is doing: Ignore that single channel.
Marc
Technical Discussion » Need help on python scripting ( Real-time viewport recorder)
- malbrecht
- 806 posts
- Offline
Hi, anonymous “Blacko0ps”(?),
a “solver” (node) gives you access to values from the previous frame in a running timeline. That is Houdini's (only) way to provide consistent data, except for setting global (environment) variables. If you want to build an array that holds XFOs (transforms) in an array “over time”, this is the reliable way to do it. Look for tutorials on “using a solver node”, also check the documentation on that node. In general I think that Houdini's documentation does a very good job, what it is lacking you can really only learn from trying things out for yourself.
The alternative approach I mentioned is a Python script node. I assume that such nodes get included once per compilation in Houdini and called as a function, and since all variables in Python are “global”, they keep their values “over time”. So you can check if a variable (e.g. an array) exists and, if not (i.e. on frame 1), initialize it, then add the current XFO to it.
In the end both solutions work the same - only that the pure Python method, in theory, also works without the timeline running (but, unfortunately, not very reliably so).
The easiest way to store transformations is to set keyframes on an object that gets moved (like I suggested above). If your setup allows for an item to be controlled by your mouse in order to capture data, I would choose this solution.
For example: If you want to capture camera motion, you can do so “live”:
Marc
a “solver” (node) gives you access to values from the previous frame in a running timeline. That is Houdini's (only) way to provide consistent data, except for setting global (environment) variables. If you want to build an array that holds XFOs (transforms) in an array “over time”, this is the reliable way to do it. Look for tutorials on “using a solver node”, also check the documentation on that node. In general I think that Houdini's documentation does a very good job, what it is lacking you can really only learn from trying things out for yourself.
The alternative approach I mentioned is a Python script node. I assume that such nodes get included once per compilation in Houdini and called as a function, and since all variables in Python are “global”, they keep their values “over time”. So you can check if a variable (e.g. an array) exists and, if not (i.e. on frame 1), initialize it, then add the current XFO to it.
In the end both solutions work the same - only that the pure Python method, in theory, also works without the timeline running (but, unfortunately, not very reliably so).
The easiest way to store transformations is to set keyframes on an object that gets moved (like I suggested above). If your setup allows for an item to be controlled by your mouse in order to capture data, I would choose this solution.
For example: If you want to capture camera motion, you can do so “live”:
Marc
Houdini Indie and Apprentice » Masterclass and Other Sample File Formats
- malbrecht
- 806 posts
- Offline
Moin,
“skipping unrecognized parameter” sounds like if you are trying to open a H16 file with a H15 version (or some similar setup where you try to open a newer version HIP with an older version of Houdini). Are you using the latest version of Houdini?
I could imagine the other way around (older file version) could, sometimes, lead to issues as well - could you give some more details on what version the tutorial files where created in and what version you are running yourself?
Marc
“skipping unrecognized parameter” sounds like if you are trying to open a H16 file with a H15 version (or some similar setup where you try to open a newer version HIP with an older version of Houdini). Are you using the latest version of Houdini?
I could imagine the other way around (older file version) could, sometimes, lead to issues as well - could you give some more details on what version the tutorial files where created in and what version you are running yourself?
Marc
Technical Discussion » 3D Mouse and camera/view pivot
- malbrecht
- 806 posts
- Offline
Definitely play with the settings - and use the learning program (if that still exists, haven't looked at it for ages).
That said, there are people who just cannot do with this style of navigation, which one has to accept. The good thing is: Those devices sell very well second hand, so if you really don't “get it”, selling it with only a small loss should be possible.
3dConnexion also has student rebates (considerable ones) and offers some trade-in. If you can find a damaged, not trade-in-marked 3dmouse, you can get some decent price drop for either shipping it in or sending proof of its destruction.
Marc
That said, there are people who just cannot do with this style of navigation, which one has to accept. The good thing is: Those devices sell very well second hand, so if you really don't “get it”, selling it with only a small loss should be possible.
3dConnexion also has student rebates (considerable ones) and offers some trade-in. If you can find a damaged, not trade-in-marked 3dmouse, you can get some decent price drop for either shipping it in or sending proof of its destruction.
Marc
Technical Discussion » 3D Mouse and camera/view pivot
- malbrecht
- 806 posts
- Offline
Hi, Chris,
I love using Stylus + 3dMouse. In fact … I often say that I refuse to use 3d software that does not sufficiently support both
For H16 I created a short overview on using a 3d mouse with hotkeys - because that might be the most important thing if you are used to a programmable mouse (with additional buttons):
Marc
I love using Stylus + 3dMouse. In fact … I often say that I refuse to use 3d software that does not sufficiently support both
For H16 I created a short overview on using a 3d mouse with hotkeys - because that might be the most important thing if you are used to a programmable mouse (with additional buttons):
Marc
Technical Discussion » 3D Mouse and camera/view pivot
- malbrecht
- 806 posts
- Offline
Moin,
I tried your suggestion and don't have any real problems with orbiting around the cubes in whatever order. Using a 3d mouse does need a bit of practise. The way it “feels to me” is: Tilting and rotating happen around a virtual center point. This center point can be moved by using the move/in-out/up-down axis. So if you want to rotate a point that is off-center (screenwise), you “side-step” the virtual center point by pushing the mouse knob to the side while rotating (the rotation center returns to viewport center once you stop using the side/updown/inout axis).
In other words: You are actually using more than one axis on the controller if you want to orbit/move around some object that is off-center on screen, but only one axis if you orbit/move around an object center-screen.
Marc
P.S. It would be nice to have a way to define an off-center rotation “pivot”, but personally I find using the viewport center as the main rotation pivot sufficient.
I tried your suggestion and don't have any real problems with orbiting around the cubes in whatever order. Using a 3d mouse does need a bit of practise. The way it “feels to me” is: Tilting and rotating happen around a virtual center point. This center point can be moved by using the move/in-out/up-down axis. So if you want to rotate a point that is off-center (screenwise), you “side-step” the virtual center point by pushing the mouse knob to the side while rotating (the rotation center returns to viewport center once you stop using the side/updown/inout axis).
In other words: You are actually using more than one axis on the controller if you want to orbit/move around some object that is off-center on screen, but only one axis if you orbit/move around an object center-screen.
Marc
P.S. It would be nice to have a way to define an off-center rotation “pivot”, but personally I find using the viewport center as the main rotation pivot sufficient.
Edited by malbrecht - March 3, 2017 03:23:24
Technical Discussion » Need help on python scripting ( Real-time viewport recorder)
- malbrecht
- 806 posts
- Offline
Moin,
you may have to set up an array in ato store the recorded data. The for-loop you are using runs within one frame, so it doesn't record over time.
In theory (actually in reality, too) you can keep a local variable (including an array) in a python node without having to loop, so you'd simply grab the current frame number and store the read data in the array. The problem with this is that evaluation of that python node is not “guaranteed”.
Maybe there is a more elegant solution, though: If you can grab an item (a null) and move it while recording, you could simply capture the position data of that null. No need for code at all.
Marc
you may have to set up an array in a
solver
In theory (actually in reality, too) you can keep a local variable (including an array) in a python node without having to loop, so you'd simply grab the current frame number and store the read data in the array. The problem with this is that evaluation of that python node is not “guaranteed”.
Maybe there is a more elegant solution, though: If you can grab an item (a null) and move it while recording, you could simply capture the position data of that null. No need for code at all.
Marc
Technical Discussion » PC for Houdini and 5000 euros max.
- malbrecht
- 806 posts
- Offline
If I should have frozen out others from participating in this discussion, I apologize. I was hoping for some more discussion, since I believe the TO got exactly ZERO out of this thread (at least she never came back to say anything).
AMD:
I am keeping more than an eye on the Ryzen discussion. Unfortunately it, again, circles around game performance, which is of almost zero interest to me, because for number crunching and UXP I do not need the fastest data transfer from CPU to GPU and back.
First tests I have read about seem to indicate that single core performance on the 1800 is not as good as hoped for. I don't find the tests too convincing, because they are based on some game engine benchmarks and I would definitely prefer trying to manually move more than a few dozen items in a scene in modo to seeing some multi-colored polygon monsters doing BVH interpretations, but at least these hints seem to be in line what I tried to discuss above: Single core performance should not be underestimated for a “work machine”, while multi core performance may be of more importance for a render slave.
In the end I guess it will be about “considerably lower price for slightly less performance”, after the dust has settled and street prices have balanced out. With the topic of this thread being about a 5k machine, I do think that there are more considerations than the CPU alone (like RAM, SSD etc).
GPU:
The 1080 ti looks promising. I fear that NVidia is pulling stunts again, they are not exactly known to be upright and honest about their specs, but price/performance ratio really looks intriguing. I'm definitely holding back on buying a 1080 until there's more trustworthy information about those cards.
Apple:
hehe. Censored everything I wrote.
Marc
AMD:
I am keeping more than an eye on the Ryzen discussion. Unfortunately it, again, circles around game performance, which is of almost zero interest to me, because for number crunching and UXP I do not need the fastest data transfer from CPU to GPU and back.
First tests I have read about seem to indicate that single core performance on the 1800 is not as good as hoped for. I don't find the tests too convincing, because they are based on some game engine benchmarks and I would definitely prefer trying to manually move more than a few dozen items in a scene in modo to seeing some multi-colored polygon monsters doing BVH interpretations, but at least these hints seem to be in line what I tried to discuss above: Single core performance should not be underestimated for a “work machine”, while multi core performance may be of more importance for a render slave.
In the end I guess it will be about “considerably lower price for slightly less performance”, after the dust has settled and street prices have balanced out. With the topic of this thread being about a 5k machine, I do think that there are more considerations than the CPU alone (like RAM, SSD etc).
GPU:
The 1080 ti looks promising. I fear that NVidia is pulling stunts again, they are not exactly known to be upright and honest about their specs, but price/performance ratio really looks intriguing. I'm definitely holding back on buying a 1080 until there's more trustworthy information about those cards.
Apple:
hehe. Censored everything I wrote.
Marc
-
- Quick Links