seems to work fine here - make sure you switch viewports a few times, the main Scene View does not always get updated correctly (I assume this is an openGL issue, because it seems to happen in other programs as well when you change geometry that is already present in the display buffer)
Marc
Found 590 posts.
Search results Show results as topic list.
Technical Discussion » Displacement not showing in viewport
- malbrecht
- 806 posts
- Offline
Houdini Learning Materials » Making/Reviewing Tutorials - Bit off topic, but best simplest Screengrap software.
- malbrecht
- 806 posts
- Offline
Moin, Sam,
I now use the NVidia GeForce Experience capturing, which does the H.264 encoding on the GPU, so it does not drain that much CPU cycles that most other recording tools come with. Besides the output files are pretty well compressed without loosing detail. If you have an NVidia card installed, that's pretty free (except for the idiotic you-have-to-register-BS).
There is a bunch of free recording software out there, what I used for quite some time was Open Broadcast Studio (https://obsproject.com/ [obsproject.com] ) - quite a few more settings to tweak to get the best balance of quality/FPS/CPU drain, but very reliable, plus it has a basic editing system built in with highlighting, zoom drive etc. I think you can even visualize mouse/key clicks, as they get recorded into a native format (and you can export MP4 out of that).
I hope this helps.
Marc
I now use the NVidia GeForce Experience capturing, which does the H.264 encoding on the GPU, so it does not drain that much CPU cycles that most other recording tools come with. Besides the output files are pretty well compressed without loosing detail. If you have an NVidia card installed, that's pretty free (except for the idiotic you-have-to-register-BS).
There is a bunch of free recording software out there, what I used for quite some time was Open Broadcast Studio (https://obsproject.com/ [obsproject.com] ) - quite a few more settings to tweak to get the best balance of quality/FPS/CPU drain, but very reliable, plus it has a basic editing system built in with highlighting, zoom drive etc. I think you can even visualize mouse/key clicks, as they get recorded into a native format (and you can export MP4 out of that).
I hope this helps.
Marc
Technical Discussion » Nightmare!poor UI behaviour
- malbrecht
- 806 posts
- Offline
Moin,
while one could claim that the resolution your monitor allows you is not exactly “up to date” (with 4k slowly becoming the new standard that replaces the de facto FullHD standard), you can easily make your options windows smaller (see attachment). If you cannot reach the bottom border to shrink the window, press ALT+Space (on Windows) to bring up the window menu, then select “move” and move the options window down a tad, so that you can grab the top border and shrink the window vertically.
Another option is to use the environment variable HOUDINI_UISCALE and set that to something smaller than 100 (the value is given in percent), that should, probably, shrink your UI elements, but might make them hard to decipher.
Marc
while one could claim that the resolution your monitor allows you is not exactly “up to date” (with 4k slowly becoming the new standard that replaces the de facto FullHD standard), you can easily make your options windows smaller (see attachment). If you cannot reach the bottom border to shrink the window, press ALT+Space (on Windows) to bring up the window menu, then select “move” and move the options window down a tad, so that you can grab the top border and shrink the window vertically.
Another option is to use the environment variable HOUDINI_UISCALE and set that to something smaller than 100 (the value is given in percent), that should, probably, shrink your UI elements, but might make them hard to decipher.
Marc
Houdini Lounge » To Character Rig... or Not
- malbrecht
- 806 posts
- Offline
Before Luiz kicks me out for going German …
Let's nitpick on your factors then:
> Houdini is Bones based and not Joints
… in my eyes: Semantics without any meaning for the real world, because if you rig in Houdini, you rig in Houdini. Different systems use different workflows. That may be enough for you to not use Houdini, but you may get very limited in the future if you insist in one specific visual representation of parenting items.
> so importing fbx for example is a complete mess.
Doesn't apply to rigging, because this is Export. Different topic.
> Ex: Ue4 skeleton is supposed to have around 63 joints, however Houdini convert it to their paradigm of bones and ends up with 136 nodes for the skeleton.
… import/export: Doesn't apply to rigging. It *is* a pipeline thing and I am sure there will be tutorials on how to deal with this better in the future.
> Even if you would create a manual UE4 skeleton, exporting a FBX generates additional _end_effector nodes and there is no way to switch this off. Trying to recreate the UE4 skeleton will not happen.
… this is about rigging in UE4, not about rigging in Houdini. Does not apply.
> How bones are shaped is also a complete mystery. What I mean with this, a bone has two ends, the base/begin and the tip. However there is no way to determine where the tip is, nor can you snap to it.
I did file a bug and I think a RFE on that topic, I think Michael is aware of the display issue. You might want to file another report on it, because it seems to be a general problem - personally I consider it a bug, not a workflow issue. And bugs have been invented to keep developers in pay.
> There is very little being done from SideFX to help people understand rigging and it seems the companies testing new features does not really use rigging in a pipeline solution.
That may be true for the past. The reason why I am now using Houdini is that Houdini 16 is the first (big) step in taking rigging and animation much more publically serious than in the past.
To me your “factors” don't describe your problems in Houdini but your specific pipeline issues - which is OK, because Houdini *is* a pipeline tool. But try to come up with suggestions - like “I would like to see this and that”
Marc
Let's nitpick on your factors then:
> Houdini is Bones based and not Joints
… in my eyes: Semantics without any meaning for the real world, because if you rig in Houdini, you rig in Houdini. Different systems use different workflows. That may be enough for you to not use Houdini, but you may get very limited in the future if you insist in one specific visual representation of parenting items.
> so importing fbx for example is a complete mess.
Doesn't apply to rigging, because this is Export. Different topic.
> Ex: Ue4 skeleton is supposed to have around 63 joints, however Houdini convert it to their paradigm of bones and ends up with 136 nodes for the skeleton.
… import/export: Doesn't apply to rigging. It *is* a pipeline thing and I am sure there will be tutorials on how to deal with this better in the future.
> Even if you would create a manual UE4 skeleton, exporting a FBX generates additional _end_effector nodes and there is no way to switch this off. Trying to recreate the UE4 skeleton will not happen.
… this is about rigging in UE4, not about rigging in Houdini. Does not apply.
> How bones are shaped is also a complete mystery. What I mean with this, a bone has two ends, the base/begin and the tip. However there is no way to determine where the tip is, nor can you snap to it.
I did file a bug and I think a RFE on that topic, I think Michael is aware of the display issue. You might want to file another report on it, because it seems to be a general problem - personally I consider it a bug, not a workflow issue. And bugs have been invented to keep developers in pay.
> There is very little being done from SideFX to help people understand rigging and it seems the companies testing new features does not really use rigging in a pipeline solution.
That may be true for the past. The reason why I am now using Houdini is that Houdini 16 is the first (big) step in taking rigging and animation much more publically serious than in the past.
To me your “factors” don't describe your problems in Houdini but your specific pipeline issues - which is OK, because Houdini *is* a pipeline tool. But try to come up with suggestions - like “I would like to see this and that”
Marc
Houdini Lounge » To Character Rig... or Not
- malbrecht
- 806 posts
- Offline
> For me a bone is simply the link between two joints. According to Houdini's docs, not so much.
yeah … sure, you can go semantic on that :-D
That documentation snippet underlines what I was trying to say. It's, at its core, the same. But visually, for the “artist”, it feels different. I am not an artist, so I don't care
> other people's experience input might be wise first.
Sounds like a good plan. It would help, though, if you could describe your experience in some more detail than just saying “Rigging in Houdini sucks because of import/export problems” or because of some phylosophical difference in how parenting items works. “Input” should, in my world, be specific, constructive, sample based. Not grumbling …
Marc
P.S. I tried to give improvement suggestions over the last 10 weeks or so, some of which got me into some discussion about (other) philosophical things, others we could agree to disagree on and some, few, may make it into some future daily build, who knows. What I tried to give were use cases where what I wished for might be helpful - I am under the impression that this smoothened out the risk of getting a “we are Houdini. We don't do like others” …
yeah … sure, you can go semantic on that :-D
That documentation snippet underlines what I was trying to say. It's, at its core, the same. But visually, for the “artist”, it feels different. I am not an artist, so I don't care
> other people's experience input might be wise first.
Sounds like a good plan. It would help, though, if you could describe your experience in some more detail than just saying “Rigging in Houdini sucks because of import/export problems” or because of some phylosophical difference in how parenting items works. “Input” should, in my world, be specific, constructive, sample based. Not grumbling …
Marc
P.S. I tried to give improvement suggestions over the last 10 weeks or so, some of which got me into some discussion about (other) philosophical things, others we could agree to disagree on and some, few, may make it into some future daily build, who knows. What I tried to give were use cases where what I wished for might be helpful - I am under the impression that this smoothened out the risk of getting a “we are Houdini. We don't do like others” …
Edited by malbrecht - Feb. 24, 2017 10:27:55
Houdini Lounge » To Character Rig... or Not
- malbrecht
- 806 posts
- Offline
Moin,
I know that for some game-oriented people this is a religious topic and discussions tend to get messy instead of constructive, yet, I feel urged to ask:
> Houdini is Bones based and not Joints
… what is the difference?
In my world a bone is the connection of two joints - done. A bone has a center (or pivot, not going into modo's separation of the both here) and, for purely visual purpose (and none technical) a “length”. You can ignore the length and what you end up with is … a joint.
As far as converting rigs between systems goes: It would be cool if we would all just used Kraken in Fabric, sure. But we don't live in a perfect world (yet) Converting rigs between systems, for quite some time, is tricky and expecting it to work “just so” feels not exactly “professional” to me. Not that “professional” would be anything one *has* to be. I love being an amateur in about every other thing I do.
But your claim that “Houdini is not going to work” is a strong word. In fact, Houdini's rigging world is very powerful - but with great power comes some slight responsibility. After all, Houdini is not a game engine, there are people who want to do *more* with it. If you want a tool that does *only* game engine stuff - use a game engine. If you want a tool that can do more, you may have to learn a bit more.
Houdini 16 has been out for a few hours now and you are already claiming that it is incapable of being used in a game pipeline - impressive.
My suggestion is: Wait for Michael Goldfarb's master class on rigging in Houdini 16 and then, if you have the knowledge, the technical background and the expertise, judge again.
My other suggestion is: Try to come up with a precise plan for improving Houdini's “game capabilities” and file a RFE to SideFX. I know they are very interested both in getting that input and trying their best to meet users' expectations.
Marc
I know that for some game-oriented people this is a religious topic and discussions tend to get messy instead of constructive, yet, I feel urged to ask:
> Houdini is Bones based and not Joints
… what is the difference?
In my world a bone is the connection of two joints - done. A bone has a center (or pivot, not going into modo's separation of the both here) and, for purely visual purpose (and none technical) a “length”. You can ignore the length and what you end up with is … a joint.
As far as converting rigs between systems goes: It would be cool if we would all just used Kraken in Fabric, sure. But we don't live in a perfect world (yet) Converting rigs between systems, for quite some time, is tricky and expecting it to work “just so” feels not exactly “professional” to me. Not that “professional” would be anything one *has* to be. I love being an amateur in about every other thing I do.
But your claim that “Houdini is not going to work” is a strong word. In fact, Houdini's rigging world is very powerful - but with great power comes some slight responsibility. After all, Houdini is not a game engine, there are people who want to do *more* with it. If you want a tool that does *only* game engine stuff - use a game engine. If you want a tool that can do more, you may have to learn a bit more.
Houdini 16 has been out for a few hours now and you are already claiming that it is incapable of being used in a game pipeline - impressive.
My suggestion is: Wait for Michael Goldfarb's master class on rigging in Houdini 16 and then, if you have the knowledge, the technical background and the expertise, judge again.
My other suggestion is: Try to come up with a precise plan for improving Houdini's “game capabilities” and file a RFE to SideFX. I know they are very interested both in getting that input and trying their best to meet users' expectations.
Marc
Houdini Indie and Apprentice » Right click menu in network editor
- malbrecht
- 806 posts
- Offline
When I right click on a node in the network editor, I get the expected context menu including parameters etc. Only clicking into an empty area brings up the tab-menu. Seems OK to me, since without hovering over a node, there is not much context to display?
Marc
Marc
Technical Discussion » autorig capture issue
- malbrecht
- 806 posts
- Offline
> Turning on Display Deform SOP did the job.
… so it wasn't all wrong in the first place
> Is there a way to sculpt in Pose Based Deforms with the rig at this point?
Depending on what workflow you prefer - generally nothing keeps you from doing that, since you can sculpt on the rigged mesh and drive the changes to the geometry based on whatever value/parameter you wish.
As far as I can see, there isn't a “streamlined artists-friendly-click-here” way for that, but technically it's pretty straight forward.
Marc
… so it wasn't all wrong in the first place
> Is there a way to sculpt in Pose Based Deforms with the rig at this point?
Depending on what workflow you prefer - generally nothing keeps you from doing that, since you can sculpt on the rigged mesh and drive the changes to the geometry based on whatever value/parameter you wish.
As far as I can see, there isn't a “streamlined artists-friendly-click-here” way for that, but technically it's pretty straight forward.
Marc
Technical Discussion » autorig capture issue
- malbrecht
- 806 posts
- Offline
Works for me …
I probably did it the same way you did: Set up the rig, placed the controls roughly where they're supposed to be, generated the rig. I *did* switch the rig to “editable” (right click on the rig folder in the network view, allow contents to be edited), because I wanted to layout the content anyway.
Then biharmonic capture with factory default settings and click on “Pose” shelf tool …
Rig attached (15 seconds placement - probably *not* production ready)
Marc
I probably did it the same way you did: Set up the rig, placed the controls roughly where they're supposed to be, generated the rig. I *did* switch the rig to “editable” (right click on the rig folder in the network view, allow contents to be edited), because I wanted to layout the content anyway.
Then biharmonic capture with factory default settings and click on “Pose” shelf tool …
Rig attached (15 seconds placement - probably *not* production ready)
Marc
Houdini Lounge » Houdini 16
- malbrecht
- 806 posts
- Offline
Thomas, I was just able to get someone up and running with H16 who had similar (but not the SAME) issues that you seem to have - for him it was a screwed up user account, creating a new user and installing Houdini for that one solved all his problems.
Maybe that helps? It's worth a try, if it fails, you can just delete the new user.
Marc
Maybe that helps? It's worth a try, if it fails, you can just delete the new user.
Marc
Technical Discussion » autorig capture issue
- malbrecht
- 806 posts
- Offline
Technical Discussion » autorig capture issue
- malbrecht
- 806 posts
- Offline
Jeff, until Michael walks into his office - could you give me the SCALE of the figure you are trying to capture? I'd quickly try to reproduce your problem here then.
Marc
Marc
Technical Discussion » autorig capture issue
- malbrecht
- 806 posts
- Offline
Moin,
two ideas (just brainstorming here):
- you don't have the deform node active (blue bemple on the right to “deform_MacMan_A”, have you tried switching it off and on again?
- you could have a peek at the capture regions, click on “Edit Capture Regions” in the shelf and check if they grab your geometry correctly (just to see if there might be a scaling issue)
Sorry for interrupting, feel free to yell at me …
Marc
two ideas (just brainstorming here):
- you don't have the deform node active (blue bemple on the right to “deform_MacMan_A”, have you tried switching it off and on again?
- you could have a peek at the capture regions, click on “Edit Capture Regions” in the shelf and check if they grab your geometry correctly (just to see if there might be a scaling issue)
Sorry for interrupting, feel free to yell at me …
Marc
Houdini Lounge » Houdini 16
- malbrecht
- 806 posts
- Offline
Moin, Will,
SpacePilot definitely is supported. Since Houdini supports the original protocol of the driver, there is nothing that the 3dConneXion driver would need to support in return (like specific Houdini commands).
They obviously haven't updated their website accordingly - after all, H16 is only out a couple of hours by now. They are, however, very much aware of H16 supporting their products - I know this first hand (from the guy at 3dConneXion responsible for making it work).
I have various 3dConneXion devices, all work perfectly in H16. Attached is a screengrab of my 2006 SpacePilot moving the Special-User-Pig-Head around.
Marc
Hi, I appreciate you taking the time to help, first I'm running on Windows, and again, I have a SpacePilot, not Mouse etc.
SpacePilot definitely is supported. Since Houdini supports the original protocol of the driver, there is nothing that the 3dConneXion driver would need to support in return (like specific Houdini commands).
2) “Houdini” is totally missing as being supported on their website.
They obviously haven't updated their website accordingly - after all, H16 is only out a couple of hours by now. They are, however, very much aware of H16 supporting their products - I know this first hand (from the guy at 3dConneXion responsible for making it work).
Now if there's someone here on Windows with a SpacePilot Pro and they have it working, or if SideFX could chime in and confirm, then that would help eliminate my confusion.
I have various 3dConneXion devices, all work perfectly in H16. Attached is a screengrab of my 2006 SpacePilot moving the Special-User-Pig-Head around.
Marc
Houdini Lounge » Houdini 16
- malbrecht
- 806 posts
- Offline
Moin, Thomas,
my comment was targeted at WillBell - because I saw your previous post about issues with the older Windows version. Personally I only tested Windows 8.1 for a few weeks and went back to 7 faster than my dogs catch mice. Win 10 works fine here, though.
The most likely issue to me seems to be a Python hickup. Do you have some global Python ENV VARs that might interfer with Houdini's Python? H is using a packaged 2.7, but it may well be possible that it tries to use your installed 3.x or whatever - and fails.
One thing you could try is set up a clean user (assuming you are setting environments for users, not globally for administrators) and check if H16/Qt5 works there. A virtual machine with a clean Windows install also comes in handy to have a quick go at comparing setups.
Else the best thing you can do is send your report to support@sidefx.com - they may be slightly drowning in requests right now, so cut them some slack
Marc
my comment was targeted at WillBell - because I saw your previous post about issues with the older Windows version. Personally I only tested Windows 8.1 for a few weeks and went back to 7 faster than my dogs catch mice. Win 10 works fine here, though.
ThomasHelzle
I can't get the qt5 version to work. I always get the errors I posted above and a blocking error window that prevents me from doing anything. This is on windows 8.1 x64.
The most likely issue to me seems to be a Python hickup. Do you have some global Python ENV VARs that might interfer with Houdini's Python? H is using a packaged 2.7, but it may well be possible that it tries to use your installed 3.x or whatever - and fails.
One thing you could try is set up a clean user (assuming you are setting environments for users, not globally for administrators) and check if H16/Qt5 works there. A virtual machine with a clean Windows install also comes in handy to have a quick go at comparing setups.
Else the best thing you can do is send your report to support@sidefx.com - they may be slightly drowning in requests right now, so cut them some slack
Marc
Houdini Lounge » Houdini 16
- malbrecht
- 806 posts
- Offline
Moin,
make sure you have downloaded the Qt5 version (a version that does *NOT* containt Qt4 in its filename), because 3dConneXion support is only available in the Qt5 version.
I hope this helps!
Marc
WillBellJr
I'm sitting here with my SpacePilot and it's not working with H16 Apprentice? Is it just a matter of having Indie or higher? Or is there a configuration profile I need to download etc?
make sure you have downloaded the Qt5 version (a version that does *NOT* containt Qt4 in its filename), because 3dConneXion support is only available in the Qt5 version.
I hope this helps!
Marc
Houdini Lounge » Houdini 16
- malbrecht
- 806 posts
- Offline
Moin,
you can add a new pane and set that to type “Autorig”, see screenshot attached.
Marc
eafreak
Hallo, I cannot seem to find the auto rig tools.
you can add a new pane and set that to type “Autorig”, see screenshot attached.
Marc
Houdini Lounge » Houdini 16
- malbrecht
- 806 posts
- Offline
Doesn't sound much like a question to me … if you are going to write out geometry / particles / pigheads, use the one with less usage on the disc, I'd say. That happens to be the faster one alltogether anyway.
Wait.
Provision management just called, I take that back.
BUY TWO.
Marc
Wait.
Provision management just called, I take that back.
BUY TWO.
Marc
Technical Discussion » PC for Houdini and 5000 euros max.
- malbrecht
- 806 posts
- Offline
> I'm very home taught and sometimes make up or use wrong terms!
hehe, all good - so am I. Homeschool gives you the most bang for the boom. Or so …
That's why I am very much interested in additional opinions …
Marc
hehe, all good - so am I. Homeschool gives you the most bang for the boom. Or so …
That's why I am very much interested in additional opinions …
Marc
Technical Discussion » PC for Houdini and 5000 euros max.
- malbrecht
- 806 posts
- Offline
Hi,
Preface: please remember that what I am saying here is personal opinion and very much open to discussion …
> I mainly do large scale flip simulation that push a lot of particles, but with GPU rendering gaining a lot of traction here's something I don't fully understand.
Mind you: Simulation and Rendering are two different beasts. Example: If you simulate fluid, you often deal with particles that you “remesh” after the simulation is done, you only *render* the surface of the generated mesh. In rendering, therefor, you don't deal with particles (in this specific case) at all.
> When you use the GPU to render out particle sims, does to CPU and GPU work together to simulate these scenes, or purely using the GPU?
That depends on your renderer (can it utilize system RAM to hold data that it cannot keep on the GPU memory?), on the way you set up the shader (are you actually rendering particles or are you meshing?) … for example (note, I am on thin ice there), as far as I know Redshift, a GPU renderer, can push data into system memory and still incooperate that into building the scene for rendering. That may not be as fast as a full onboard-GPU rendering, but it might still be faster than CPU rendering - depends on scene, setup and, probably, phase of the moon.
> Is there a limitation with using openCL that would make more sense not to use it?
This question, I think, is not really related to the above: Cuda, openCL etc. are just ways to address the GPU and make it “do something” - WHAT you actually do depends on the software package you use. For simulation in Houdini, for example, it depends on what calculations developers have “translated” into openCL.
> Or should you almost always use OpenCL when doing large scale flip sims?
See above: It depends on what your software package or its developers actually push into the GPU, I don't think that there is any “general” answer to the question “should I always use openCL or Cuda for FLIP simulations”. I would guess that this kind of simulation almost always is *faster* on modern high end GPUs, but that's an educated guess, nothing more. Who is to say that the next or one after that generation of CPUs does not come with a built in DSP chip for simulations?
Sorry, no really definite answers here, I think it's really up to people *testing* specific scenes and coming up with numbers.
For example: In Fabric the core developers tend to only multi-thread geometry manipulation if more than 1000 points are to be handled, else they keep it all on one thread. This is, of course, just a ball-park-number that might not actually fit your specific geometry that well. Now considering that piping data back and forth to GPU might be another bottleneck (maybe data has to be sorted/prepped in a specific way), you might only start with 20k points to even consider GPU usage - this is a wild guess, no real number.
Or, if the actual calculation only takes half a second on CPU and only 100ms on a GPU, but preparing data and piping it back and forth takes more than 2 seconds … using the GPU wouldn't help.
Marc
Preface: please remember that what I am saying here is personal opinion and very much open to discussion …
> I mainly do large scale flip simulation that push a lot of particles, but with GPU rendering gaining a lot of traction here's something I don't fully understand.
Mind you: Simulation and Rendering are two different beasts. Example: If you simulate fluid, you often deal with particles that you “remesh” after the simulation is done, you only *render* the surface of the generated mesh. In rendering, therefor, you don't deal with particles (in this specific case) at all.
> When you use the GPU to render out particle sims, does to CPU and GPU work together to simulate these scenes, or purely using the GPU?
That depends on your renderer (can it utilize system RAM to hold data that it cannot keep on the GPU memory?), on the way you set up the shader (are you actually rendering particles or are you meshing?) … for example (note, I am on thin ice there), as far as I know Redshift, a GPU renderer, can push data into system memory and still incooperate that into building the scene for rendering. That may not be as fast as a full onboard-GPU rendering, but it might still be faster than CPU rendering - depends on scene, setup and, probably, phase of the moon.
> Is there a limitation with using openCL that would make more sense not to use it?
This question, I think, is not really related to the above: Cuda, openCL etc. are just ways to address the GPU and make it “do something” - WHAT you actually do depends on the software package you use. For simulation in Houdini, for example, it depends on what calculations developers have “translated” into openCL.
> Or should you almost always use OpenCL when doing large scale flip sims?
See above: It depends on what your software package or its developers actually push into the GPU, I don't think that there is any “general” answer to the question “should I always use openCL or Cuda for FLIP simulations”. I would guess that this kind of simulation almost always is *faster* on modern high end GPUs, but that's an educated guess, nothing more. Who is to say that the next or one after that generation of CPUs does not come with a built in DSP chip for simulations?
Sorry, no really definite answers here, I think it's really up to people *testing* specific scenes and coming up with numbers.
For example: In Fabric the core developers tend to only multi-thread geometry manipulation if more than 1000 points are to be handled, else they keep it all on one thread. This is, of course, just a ball-park-number that might not actually fit your specific geometry that well. Now considering that piping data back and forth to GPU might be another bottleneck (maybe data has to be sorted/prepped in a specific way), you might only start with 20k points to even consider GPU usage - this is a wild guess, no real number.
Or, if the actual calculation only takes half a second on CPU and only 100ms on a GPU, but preparing data and piping it back and forth takes more than 2 seconds … using the GPU wouldn't help.
Marc
-
- Quick Links