The thing I'm most interested in about any Quadro P4000 or Quadro RTX 000's equivalent and up is, do we really get better drivers with these cards in linux or would that be the wrong reason to purchase a quadro?
I experience painfully unreliable viewports and open gl rop rendering with 2 different 1080 TI's in houdini. is my experience going to be any better with a P5000? Are the quadro drivers really giving me anything?
Things have gotten better generally in houdini, but theres still plenty of times viewing a packed/unpacked poly object seems to bug out and draw a tonne of vertices at world 0 and the only way to make it go away is force a recook on the node.
Thanks if anyone could shed light on this!
Found 8 posts.
Search results Show results as topic list.
Technical Discussion » NVIDIA Quadro P4000 with Houdini?
- queglay
- 8 posts
- Offline
Technical Discussion » Problem with geometry().freeze()
- queglay
- 8 posts
- Offline
I'm reviving this old thread, since its the only place I've seen talk about the python hou geometry freeze function.
I'm trying to wrap my head around this, but it doesn't make sense to me-
with freeze, is it possible to stash geometry within a hip file and ensure it wont be destroyed even if the input is disconnected?
It sounds like it could be similar to locking a node, but I've tried to achieve this behaviour without any luck. Are there any examples that can show its usage? I'm not sure if I'm on the wrong track here for what this function could be used for.
I'm hoping to be able to store some point data within an otl for moddeling. I'm trying to avoid writing the data out to disk. using a locked node would be nice, except it can't be done inside a locked otl. I don't want to lock the otl though, because that seems to break versioned updates to the otl.
Thanks if anyone has pointers.
I'm trying to wrap my head around this, but it doesn't make sense to me-
with freeze, is it possible to stash geometry within a hip file and ensure it wont be destroyed even if the input is disconnected?
It sounds like it could be similar to locking a node, but I've tried to achieve this behaviour without any luck. Are there any examples that can show its usage? I'm not sure if I'm on the wrong track here for what this function could be used for.
I'm hoping to be able to store some point data within an otl for moddeling. I'm trying to avoid writing the data out to disk. using a locked node would be nice, except it can't be done inside a locked otl. I don't want to lock the otl though, because that seems to break versioned updates to the otl.
Thanks if anyone has pointers.
Technical Discussion » houdini flipbooks break down with high res fluid surface - dropping frames on some objects, but not the fluid.
- queglay
- 8 posts
- Offline
If I use an object merge to bring all the data into one object, that extra animating object evaluates fine, but the fluid surface flickers occasionally. still, is an expensive way to work around it and uses a fair amount of memory.
Edited by queglay - March 26, 2019 20:30:44
Technical Discussion » houdini flipbooks break down with high res fluid surface - dropping frames on some objects, but not the fluid.
- queglay
- 8 posts
- Offline
The issue I see is this - if I produce a flipbook with a fluid surface (mesh geo) and there is perhaps some other interactive object in the scene, there is a certain resolution you will hit in that mesh geo where other elements will drop frames. what makes it super weird is the flip fluid wont drop frames, its fine. but the other geo interacting with the fluid will either hold frames or drop frames completely, and its the lighter of the geo to be flipped. it hapens with both packed and unpacked objects
I've seen this with the flipbook tool and the opengl rop. what makes it hard to debug is it only happens in scenes when the resolution is being cranked up, so its hard to provide an example since there is always sensitive production data in there so I can't really provide a hip file for it, but I have seen it over quite a few shows, on different workstations, different studios since Houdini 15 or 16. I can't recall seeing it before then.
I should also note that the issue can occur without maxing out the video ram either.
I've seen this with the flipbook tool and the opengl rop. what makes it hard to debug is it only happens in scenes when the resolution is being cranked up, so its hard to provide an example since there is always sensitive production data in there so I can't really provide a hip file for it, but I have seen it over quite a few shows, on different workstations, different studios since Houdini 15 or 16. I can't recall seeing it before then.
I should also note that the issue can occur without maxing out the video ram either.
PDG/TOPs » how to get an overview of threads per task?
- queglay
- 8 posts
- Offline
Hey Guys.
is it possible to see how many threads are running on a task? I can see how many tasks are running, but not necessarily how many threads that equates to. it would be great to get a breakdown of the thread utilisation and what nodes using in terms of threads and ram. could be nice see total threads and ram usage per tops node in the network!
The other question I have is, lets say I have a precache, then sim. If the sim will not take all threads so the precache can do its thing thats fine, but once those threads from the precache free up, are they able to dynamically jump on and help the sim? or is the sim only going to use whats available from the minimum required to get started and be locked from there?
is it possible to see how many threads are running on a task? I can see how many tasks are running, but not necessarily how many threads that equates to. it would be great to get a breakdown of the thread utilisation and what nodes using in terms of threads and ram. could be nice see total threads and ram usage per tops node in the network!
The other question I have is, lets say I have a precache, then sim. If the sim will not take all threads so the precache can do its thing thats fine, but once those threads from the precache free up, are they able to dynamically jump on and help the sim? or is the sim only going to use whats available from the minimum required to get started and be locked from there?
Edited by queglay - March 25, 2019 18:00:06
Houdini Lounge » PyroFX smoke bug
- queglay
- 8 posts
- Offline
I've seen this in different solvers, not just houdini.
I can often reproduce the problem with turbulence alone, and it is often evident with high magnitude in the turbulence - I believe the culprit to be the non divergent grid / pressure solve dealing with high velocities/when turbulence is high.
Consider this- if turbulence is extremely high and constant everywhere, how does the pressure solve resolve this? I would expect it to create the artifacts we see in an imperfect algorithm. I suspect that the magnitude in the equation is favouring the xyz vectors, potentially it doesn't correct the pressure properly based on length but instead favours the magnitude isolated in each axis seperately. creating xyz noise within a box domain (instead of spherical) can do similar things.
Thats my best guess. I come across this in different situations over the years and it would be a good one to crack. I often get it to go away by cracking open turbulence in pyro and trying different noise for turb velocities.
another guess that is related is - I also wonder what happens in a pressure solve when a velocity vector is perpendicular to the grid and aligned with an opposing vector… seems like keeping only the non divergent component in this situation could be unrealistic and nasty.
this would explain the artifacts too - it appears like velocity can be killed completely in these artifacts by the non divergent grid solve which would explain also why we see these perpendicular artifacts.
I can often reproduce the problem with turbulence alone, and it is often evident with high magnitude in the turbulence - I believe the culprit to be the non divergent grid / pressure solve dealing with high velocities/when turbulence is high.
Consider this- if turbulence is extremely high and constant everywhere, how does the pressure solve resolve this? I would expect it to create the artifacts we see in an imperfect algorithm. I suspect that the magnitude in the equation is favouring the xyz vectors, potentially it doesn't correct the pressure properly based on length but instead favours the magnitude isolated in each axis seperately. creating xyz noise within a box domain (instead of spherical) can do similar things.
Thats my best guess. I come across this in different situations over the years and it would be a good one to crack. I often get it to go away by cracking open turbulence in pyro and trying different noise for turb velocities.
another guess that is related is - I also wonder what happens in a pressure solve when a velocity vector is perpendicular to the grid and aligned with an opposing vector… seems like keeping only the non divergent component in this situation could be unrealistic and nasty.
this would explain the artifacts too - it appears like velocity can be killed completely in these artifacts by the non divergent grid solve which would explain also why we see these perpendicular artifacts.
Edited by queglay - April 20, 2018 06:00:58
Technical Discussion » HDK SOP_Star sample cmake build fail on macos
- queglay
- 8 posts
- Offline
Technical Discussion » HDK SOP_Star sample cmake build fail on macos
- queglay
- 8 posts
- Offline
I had this problem as well. I updated to 16.5.367, and running cmake I managed to generate the build files. when I ran make I got this warning though-
Audios-MacBook-Pro:build Audio$ make [ 33%] Generating SOP_Star.proto.h Scanning dependencies of target SOP_Star [ 66%] Building CXX object CMakeFiles/SOP_Star.dir/SOP_Star.C.o /Users/Audio/samples/SOP/SOP_Star/SOP_Star.C:203:19: warning: unused variable 'primoff' [-Wunused-variable] GA_Offset primoff = detail->appendPrimitivesAndVertices(GA_PRIMPOLY, 1, npoints, start_vtxoff, true); ^ 1 warning generated. [100%] Linking CXX shared library /Users/Audio/Library/Preferences/houdini/16.5/dso/SOP_Star.dylib [100%] Built target SOP_Star Audios-MacBook-Pro:build Audio$
-
- Quick Links