Hi,
> How does it work for people who have ZERO ideas about programming or scripting /
… the book was written with people with “zero ideas about programming or scripting” in mind. It is very probably not so much for people who know how to write scripts or who are savvy in one programming language or another.
“Look inside the book” is available on Amazon (click on “look inside” top right corner of the cover image), so you can have a peek and decide for yourself if this is “talking to you”.
Marc
Found 590 posts.
Search results Show results as topic list.
Houdini Lounge » Book about "Becoming a Programmer": Marc Albrecht's "The Jerk's Guide to ..."
- malbrecht
- 806 posts
- Offline
Technical Discussion » AERODYNAMIC CLOTH
- malbrecht
- 806 posts
- Offline
Moin,
you don't have to use FEM for cloth-solving in 16.x or before. One workaround always is to use a straight-forward PBD setup (“grains” in Houdini).
If I remember correctly (it's quite some time that I did the research for my “everything you ever wanted to know about cloth simulations” book that I might write one day), Houdini does NOT use FEM if your object does not have any thickness. You *can* use FEM (adding “virtual thickness” to embed the tets), but you don't have to. Meaning: If you *can* use thickness-free objects to drive your simulations, you should automatically be using a hybrid or even plain PBD simulation anyway.
Docs said (again, quoting from memory, don't lynch me if I'm wrong) that you can change the type of simulation by diving into the simulation object and change the respective setting - that did not work for me on some tests but did do something on others. It's worth having a look, me guesses.
I hope any of this is of help!
Marc
you don't have to use FEM for cloth-solving in 16.x or before. One workaround always is to use a straight-forward PBD setup (“grains” in Houdini).
If I remember correctly (it's quite some time that I did the research for my “everything you ever wanted to know about cloth simulations” book that I might write one day), Houdini does NOT use FEM if your object does not have any thickness. You *can* use FEM (adding “virtual thickness” to embed the tets), but you don't have to. Meaning: If you *can* use thickness-free objects to drive your simulations, you should automatically be using a hybrid or even plain PBD simulation anyway.
Docs said (again, quoting from memory, don't lynch me if I'm wrong) that you can change the type of simulation by diving into the simulation object and change the respective setting - that did not work for me on some tests but did do something on others. It's worth having a look, me guesses.
I hope any of this is of help!
Marc
Houdini Lounge » Book about "Becoming a Programmer": Marc Albrecht's "The Jerk's Guide to ..."
- malbrecht
- 806 posts
- Offline
Preface: Forum management, please move to the appropriate place, if this is not it (permission to post in general granted by Christopher H.)
Finally out: The Jerk’s Guide to Becoming a Programmer
[www.amazon.com]
You have no idea how to write even the most simple script?
This book gets you started. It explains what a script is, what is so simple about a script and what the heck an idea has to do with it.
You want/need/have to write a complex solution to an even more complex problem and neither know where to start nor what to do in the first place?
This book guides you through the valley of despair, the desert of knowledgelesness and the wastelands of problem-o-phobia.
You are afraid of dragons?
Read this book. Really. Read it. It won't help with your fear of dragons but you cannot have it all, can you?
I have been a programmer, software developer and project possible-maker for nearing 40 years. I have learned how to program by hacking other people's software (in machine code - I explain what that is in this book), by fixing other people's software (in BASIC - I explain what that is in this book, too) and by solving other people's problems (in lots of meetings - I do not explain what that is in this book, but I do mention them).
Alas, fear not, this is not an autobiography. This book is about how to THINK like a programmer, how to approach even the most complicated problem and hack and slack and slay it down till it can beep no more - and how to get a job DONE. Before you start writing code.
Print version available through Amazon, eBook will be published ASAP.
What does this have to do with Houdini?
This book is 101% language-agnostic. The basic ideas (don't worry, I don't do BASIC here) apply to visual programming (nodal networks) just the same as to any written computer-language. No magic involved. Use VEX, Python, HScript, C/C++ or whatever your heart desires: Just have a plan and know where you're heading.
That it has to do with Houdini.
Finally out: The Jerk’s Guide to Becoming a Programmer
[www.amazon.com]
You have no idea how to write even the most simple script?
This book gets you started. It explains what a script is, what is so simple about a script and what the heck an idea has to do with it.
You want/need/have to write a complex solution to an even more complex problem and neither know where to start nor what to do in the first place?
This book guides you through the valley of despair, the desert of knowledgelesness and the wastelands of problem-o-phobia.
You are afraid of dragons?
Read this book. Really. Read it. It won't help with your fear of dragons but you cannot have it all, can you?
I have been a programmer, software developer and project possible-maker for nearing 40 years. I have learned how to program by hacking other people's software (in machine code - I explain what that is in this book), by fixing other people's software (in BASIC - I explain what that is in this book, too) and by solving other people's problems (in lots of meetings - I do not explain what that is in this book, but I do mention them).
Alas, fear not, this is not an autobiography. This book is about how to THINK like a programmer, how to approach even the most complicated problem and hack and slack and slay it down till it can beep no more - and how to get a job DONE. Before you start writing code.
Print version available through Amazon, eBook will be published ASAP.
What does this have to do with Houdini?
This book is 101% language-agnostic. The basic ideas (don't worry, I don't do BASIC here) apply to visual programming (nodal networks) just the same as to any written computer-language. No magic involved. Use VEX, Python, HScript, C/C++ or whatever your heart desires: Just have a plan and know where you're heading.
That it has to do with Houdini.
Edited by malbrecht - June 22, 2018 16:23:55
Technical Discussion » Mocap Retarget To FBX RIG?
- malbrecht
- 806 posts
- Offline
Moin,
in my experience, the biggest problem with retargeting is taking care of (limb) scaling. If your mocap knots do not match your target knots you are getting all kinds of offset issues. I started writing a tool that tried to compensate for that, but it's not trivial for arbitrary mocap files. So I ended up writing a rig-dependent script that would “simply” convert the mocap data scaling to match the respective rig.
Things like this could be (semi-)automated, but will probably always suffer from vastly varying rigs and data. There is a reason for Motion Builder's existence.
You asked:
I would still like to write a “poor-man's motion builder”, even inside/for Houdini, but my fear is that this would still be a huge task and (paying) users are hard to come by. Today everyone who isn't a “big studio” tends to demand everything for free :-/
Marc
in my experience, the biggest problem with retargeting is taking care of (limb) scaling. If your mocap knots do not match your target knots you are getting all kinds of offset issues. I started writing a tool that tried to compensate for that, but it's not trivial for arbitrary mocap files. So I ended up writing a rig-dependent script that would “simply” convert the mocap data scaling to match the respective rig.
Things like this could be (semi-)automated, but will probably always suffer from vastly varying rigs and data. There is a reason for Motion Builder's existence.
You asked:
So how do the big studios do it?and, in my world, the best answer to your specific question has been given by Michael Goldfarb: Use the right tool for the job.
I would still like to write a “poor-man's motion builder”, even inside/for Houdini, but my fear is that this would still be a huge task and (paying) users are hard to come by. Today everyone who isn't a “big studio” tends to demand everything for free :-/
Marc
Edited by malbrecht - May 19, 2018 06:55:37
Technical Discussion » Houdni and Substance Painter link?
- malbrecht
- 806 posts
- Offline
Moin, Tanel,
I assume that your questions can better be answered on the Allegorithmic forums, since this is more of a Houdini forum
This is what I *think*:
> 1. Using this plugin can i texture in Substance and take textures to Houdini and build VFX effect on top of the model while having those textures?
I would guess so. From what I have seen, the “plugin” uses a bridge that grants you access to Painter's “full functionality”. I would think that reading in pre-made textures (images) shouldn't be a problem.
> 2. Is there a plugin also for Houdni and Substance Designer
I haven't heard of it. The bridge used for Painter should, as far as I understand it, basically work for Designer, too, but you probably have to “design” (sorry the pun) the plugin on Houdini side.
Again, as far as I understand, support from users was underwhelming for the guy who developed the Painter-integration, if you aren't going to sponsor him for a Designer version, I have my doubts that he is going to invest into a Designer version …
> 3. Is there similar plugin for Mari and Houdini?
Not that I have heard of, but I have technical doubts about this working in a similar fashion. Part of Mari's “power” comes from its specific viewport that you cannot just “reproduce” in Houdini. If it was possible to “pop in” a Mari viewport into Houdini, this might work to some degree. Since Mari's isn't about painting only but works as a pipeline tool (data management), too, my assumption here is that an integration would be more of a hack like GoZ, not a real integration (where data flow from one application is “docked into” another application). And dealing with huge amounts of data, which Mari has been designed for, would not be fun using a hack like GoZ (exporting, import, natively handle, export, import …)
Marc
I assume that your questions can better be answered on the Allegorithmic forums, since this is more of a Houdini forum
This is what I *think*:
> 1. Using this plugin can i texture in Substance and take textures to Houdini and build VFX effect on top of the model while having those textures?
I would guess so. From what I have seen, the “plugin” uses a bridge that grants you access to Painter's “full functionality”. I would think that reading in pre-made textures (images) shouldn't be a problem.
> 2. Is there a plugin also for Houdni and Substance Designer
I haven't heard of it. The bridge used for Painter should, as far as I understand it, basically work for Designer, too, but you probably have to “design” (sorry the pun) the plugin on Houdini side.
Again, as far as I understand, support from users was underwhelming for the guy who developed the Painter-integration, if you aren't going to sponsor him for a Designer version, I have my doubts that he is going to invest into a Designer version …
> 3. Is there similar plugin for Mari and Houdini?
Not that I have heard of, but I have technical doubts about this working in a similar fashion. Part of Mari's “power” comes from its specific viewport that you cannot just “reproduce” in Houdini. If it was possible to “pop in” a Mari viewport into Houdini, this might work to some degree. Since Mari's isn't about painting only but works as a pipeline tool (data management), too, my assumption here is that an integration would be more of a hack like GoZ, not a real integration (where data flow from one application is “docked into” another application). And dealing with huge amounts of data, which Mari has been designed for, would not be fun using a hack like GoZ (exporting, import, natively handle, export, import …)
Marc
Edited by malbrecht - April 8, 2018 03:27:20
Technical Discussion » Euphoria like character physics simulation in Houdini
- malbrecht
- 806 posts
- Offline
Moin,
> Is it possible to produce character physics simulation like Morpheme/euphoria in Houdini? Like blending from a
semi ragdoll state to a animation or a character falling down and then getting back up from a ragdoll state?
Yes.
However, if you are looking for a click-and-be-done-solution, you might get disappointed. You can *develop* things like what you described in Houdini (e.g. by controlling the amount to which points get influenced by simulation or by animation, “blending” from one to the other), but luckily there is no shelf-tool that will get the job done for you pronto.
Marc
> Is it possible to produce character physics simulation like Morpheme/euphoria in Houdini? Like blending from a
semi ragdoll state to a animation or a character falling down and then getting back up from a ragdoll state?
Yes.
However, if you are looking for a click-and-be-done-solution, you might get disappointed. You can *develop* things like what you described in Houdini (e.g. by controlling the amount to which points get influenced by simulation or by animation, “blending” from one to the other), but luckily there is no shelf-tool that will get the job done for you pronto.
Marc
Technical Discussion » Python to Vex
- malbrecht
- 806 posts
- Offline
Moin,
I am not quite sure I completely got the problem you are facing. If you aren't sure about what code snippet is Python and what is VEX, just have a look at how conditional clauses end - Python has a colon (“:”) and almost all other languages (including VEX) don't. Python uses indentation only, almost all other languages use brackets (curly ones, usually - { and } ). You should be able to spot which language a code snippet is in by looking at it in most cases if the choice is Python or not Python :-)
As for “age of tutorials”: I do get that problem to some degree. However, I think you are taking the wrong approach here. A tutorial shouldn't be a “copy me and get rich” documentation but an explanation of how things work. They should make you understand the ways to USE the tool.
Those ways haven't really changed a lot over the time. Yes, nodes may behave differently, new nodes have been added, the programming language used in nodes may have changed - but at its core, Houdini is about controlling points. My advice would be to separate the programming stuff from understanding Houdini's “usage logic” and not intertwine both like “you HAVE to learn VEX in order to use Houdini”.
Actually, in my world watching a tutorial and then trying to redo it ON YOUR OWN, just following the general outline but “researching” your way through the current version of the software (or a completely different software for that matter) is the best way to LEARN something based on tutorials. Just copying what is being done in the video has never ever worked for me if I wanted to LEARN something …
Just a thought, though.
Marc
I am not quite sure I completely got the problem you are facing. If you aren't sure about what code snippet is Python and what is VEX, just have a look at how conditional clauses end - Python has a colon (“:”) and almost all other languages (including VEX) don't. Python uses indentation only, almost all other languages use brackets (curly ones, usually - { and } ). You should be able to spot which language a code snippet is in by looking at it in most cases if the choice is Python or not Python :-)
As for “age of tutorials”: I do get that problem to some degree. However, I think you are taking the wrong approach here. A tutorial shouldn't be a “copy me and get rich” documentation but an explanation of how things work. They should make you understand the ways to USE the tool.
Those ways haven't really changed a lot over the time. Yes, nodes may behave differently, new nodes have been added, the programming language used in nodes may have changed - but at its core, Houdini is about controlling points. My advice would be to separate the programming stuff from understanding Houdini's “usage logic” and not intertwine both like “you HAVE to learn VEX in order to use Houdini”.
Actually, in my world watching a tutorial and then trying to redo it ON YOUR OWN, just following the general outline but “researching” your way through the current version of the software (or a completely different software for that matter) is the best way to LEARN something based on tutorials. Just copying what is being done in the video has never ever worked for me if I wanted to LEARN something …
Just a thought, though.
Marc
Houdini Lounge » Cloth's slow speed
- malbrecht
- 806 posts
- Offline
Please - no - don't be embarrassed! Even if we are all just plain wrong (which I don't believe we are), every discussion, every thought, every brainstorm can shed some light on the topic.
And may help one or another looking for ideas how to solve a problem!
(That said, I am pretty sure Houdini's docs say that Houdini uses tets and tets exclusively for FEM - and I *think* I remember it also saying that a FEM cloth is being created by adding virtual thickness. But I am not sure which part of the docs actually said that - I wish the docs would include developer tidbits that give some behind-the-scenes insights. I find reading a source code often more helpful than studying the PR material …)
Marc
And may help one or another looking for ideas how to solve a problem!
(That said, I am pretty sure Houdini's docs say that Houdini uses tets and tets exclusively for FEM - and I *think* I remember it also saying that a FEM cloth is being created by adding virtual thickness. But I am not sure which part of the docs actually said that - I wish the docs would include developer tidbits that give some behind-the-scenes insights. I find reading a source code often more helpful than studying the PR material …)
Marc
Houdini Lounge » Cloth's slow speed
- malbrecht
- 806 posts
- Offline
I am not at a Houdini-fied system right now, but if I remember correctly: When you create a FEM object, the embedded tets get their own “node-thread” inside the mesh/geometry network (outside the DOP network), there is a parallel “render geometry” and a “FEM tets” thread after you created a FEM based simulation.
The “cloth” shelf tools are not “100% FEM” if I remember correctly. I asked SideFX about what simulation type 16.x is actually using for cloth, since the shelf-tool-cloth sims don't behave like PBD and don't behave like FEM. I think it actually is a kind of hybrid when you use those tools.
Marc
The “cloth” shelf tools are not “100% FEM” if I remember correctly. I asked SideFX about what simulation type 16.x is actually using for cloth, since the shelf-tool-cloth sims don't behave like PBD and don't behave like FEM. I think it actually is a kind of hybrid when you use those tools.
Marc
Houdini Lounge » Cloth's slow speed
- malbrecht
- 806 posts
- Offline
I wouldn't expect FEM solver is re-discratizing mesh it creates elements on. I would rather assume it builds elements (tetra, cubes, whatever) based on provided polygons.
It isn't rebuilding the mesh, instead, the (rendered) mesh is “wrapped” around the (tets) elements that get “filled” into the (closed) mesh. For single-plane sims, a virtual “mini-volume” is filled with tets. You can actually display the tets making up the simulated “blob” in Houdini.
In that respect, yes, the number of tets will increase if your mesh gets more complex. But the number of tets is not dependent on the number of polygons of the original mesh. You can influence how many tets are being used to represent the reference mesh.
Marc
P.S. I may be completely wrong, but this understanding is how I have been using the FEM cloth approach in Houdini so far, with some good results …
Houdini Lounge » Cloth's slow speed
- malbrecht
- 806 posts
- Offline
symek
Houdini's cloth manageable as long as optimal conditions are met.
I cannot agree more than I already do.
(albeit old Syflex turned out to be also very accurate).
Syflex is very fast, but I wouldn't call it “accurate” when it comes to *physical* simulations. You have to “play” with parameters to make the results *look* plausible. But since it is fast and stable, that is actually more fun than using a “physically correct simulation”, that just takes ages to cook.
Interestingly, once your mesh is optimal the solver doesn't seem to care much about polygons count.
Which, with FEM, is to be expected, since FEM stands for “Finite Element Method”, your mesh gets “replaced” by the specified amount of (finite) elements. That's the whole magic. So it doesn't matter how many polygons your mesh has: FEM is replacing it anyway.
Marc
Houdini Lounge » Cloth's slow speed
- malbrecht
- 806 posts
- Offline
Aside from the question why anyone would WANT to “sim” a three-layer-cloth anyway … my first suggestion is, of course, to separate the sims into layers, too. Bake sim to the inner layer, sim the middle layer, bake that, sim the outer layer.
If you can use PBD (with its drawbacks), use the grains solver. It “handles collisions better” in certain situations.
Use the tool that fits the job
Marc
If you can use PBD (with its drawbacks), use the grains solver. It “handles collisions better” in certain situations.
Use the tool that fits the job
Marc
Technical Discussion » autorig capture issue
- malbrecht
- 806 posts
- Offline
Technical Discussion » cloth object wont read animated attributes
- malbrecht
- 806 posts
- Offline
thexon
the cloth object reads the geo only on the creation frame
well … after an initial frame providing initial point-positions of a simulated object, a simulation is thought to simulate where those points go … if you wanted the geo to control where the points go, you wouldn't be simulating, would you.
this means animated attributes cannot be used,
that depends on what you mean by that. It is, of course, possible to introduce animation into a simulation. Say, you are morphing a ball into various shapes - those shapes you could always read in as target deformations and control the “blending” between simulated point positions and “source” point positions by the two target parameters.
this is a major limitation.
this, too, depends on what you mean by “this”. Since “animated attributes” (whatever you mean by it) probably *can* be used, that cannot be a limitation
Marc
Technical Discussion » autorig capture issue
- malbrecht
- 806 posts
- Offline
Hi,
so, I did a quick rig with SimpleGuy. I hope this helps you out:
- picture 1: When you activate “create capture/deform network” in the autorig, that will actually be created
- picture 2: … however, it is not fully activated. Once you are done with the autorig and your rig setup (node) has been created, set its modification state to “allowed” (i.e. allow editing of content), then go to the right most top corner, where the chops and imports are
- there you find the imported geo node, which contains the CREATED but not EXECUTED setup for capturing and deforming
- picture 3: if you just activate “deform”, you will get an error claiming that there isn't anything to do … try “Stash Input” on the stash node, if that doesn't update, activate the capture node (whatever mode you used, in the screenshot I obviously opted for biharmonic) to let that execute once.
- then, obviously, set “deform1” as the active node again, else you would not get no deformation/satisfaction not.
Marc
so, I did a quick rig with SimpleGuy. I hope this helps you out:
- picture 1: When you activate “create capture/deform network” in the autorig, that will actually be created
- picture 2: … however, it is not fully activated. Once you are done with the autorig and your rig setup (node) has been created, set its modification state to “allowed” (i.e. allow editing of content), then go to the right most top corner, where the chops and imports are
- there you find the imported geo node, which contains the CREATED but not EXECUTED setup for capturing and deforming
- picture 3: if you just activate “deform”, you will get an error claiming that there isn't anything to do … try “Stash Input” on the stash node, if that doesn't update, activate the capture node (whatever mode you used, in the screenshot I obviously opted for biharmonic) to let that execute once.
- then, obviously, set “deform1” as the active node again, else you would not get no deformation/satisfaction not.
Marc
Edited by malbrecht - Feb. 25, 2018 10:59:28
Technical Discussion » autorig capture issue
- malbrecht
- 806 posts
- Offline
I'll try my best once I am home. I don't have access to Houdini on the gig I'm working and I don't get home before I am done here …
From memory: After you created the rig, you have to create a weight map. That's a separate step. Once that map is created, every bone gets a “part” of that map assigned. Deformation (for animation) can only work if you have a skeleton (bones) and weights assigned to the bones, else you are just dealing with a mesh and a skeleton that don't have any “connection”.
Sorry that I cannot do better from where I am sitting. As soon as I can boot up a Houdini, I'll do some screenshots (more likely someone else will pop in here and just give THE ANSWER though )
Marc
From memory: After you created the rig, you have to create a weight map. That's a separate step. Once that map is created, every bone gets a “part” of that map assigned. Deformation (for animation) can only work if you have a skeleton (bones) and weights assigned to the bones, else you are just dealing with a mesh and a skeleton that don't have any “connection”.
Sorry that I cannot do better from where I am sitting. As soon as I can boot up a Houdini, I'll do some screenshots (more likely someone else will pop in here and just give THE ANSWER though )
Marc
Technical Discussion » autorig capture issue
- malbrecht
- 806 posts
- Offline
Hi, Henry,
thanks for the details, that's helping.
I don't have Houdini available for about 3-4 days until I get back home, else I would try to reproduce the problem.
In general, the autorig does not use anything that you wouldn't or couldn't use when creating a rig yourself, it's just “standard” bones. The weights are only being created when you actually do a weighting (e.g. biharmonic), before that you are only dealing with the skeleton. Do you have weights created?
Once weightmaps are created you can definitely use the “standard” tools (like paint-adjusting a weight map) by plugging in an edit node into the weighting workflow (graph).
What happens when you try to adjust a bone's map?
Marc
thanks for the details, that's helping.
I don't have Houdini available for about 3-4 days until I get back home, else I would try to reproduce the problem.
In general, the autorig does not use anything that you wouldn't or couldn't use when creating a rig yourself, it's just “standard” bones. The weights are only being created when you actually do a weighting (e.g. biharmonic), before that you are only dealing with the skeleton. Do you have weights created?
Once weightmaps are created you can definitely use the “standard” tools (like paint-adjusting a weight map) by plugging in an edit node into the weighting workflow (graph).
What happens when you try to adjust a bone's map?
Marc
Technical Discussion » autorig capture issue
- malbrecht
- 806 posts
- Offline
thejedi
Hello, I am struggling to do what weight capture to my autorig
Can you please share how you did it?
Sorry, could you please explain your question? Showing some images of how far you got, maybe a (simplified!!!) test HIP file would make sense … and then, please, try to be SPECIFIC in your question.
Else we (or, well, maybe just me) need a help-forum for interpreting help-questions …
Marc
Technical Discussion » Very slow
- malbrecht
- 806 posts
- Offline
Hi,
like cpb says, a HIP file for experimentation always is a good idea.
> every time I move the curve it takes a long time to recalculate
… you might consider caching the state of your procedural construction and only recook on the click of a button - have a read on caching results, file caches etc. Because if you *do* recook upon on every input change, you will always run into user experience issues.
Sometimes it makes sense to use proxy geometry / simplified representations for setup purpose and have a switch somewhere that applies what you created with the proxies to the actual “render” geometry. This is more “UXP design” than “procedural thinking”, but with a fully procedural workflow you have to consider both.
On Mantra rendering and speeding it up there are some discussions around here, some tutorials and even one or two masterclasses. In the end, if you want “really fast rendering”, you may have to consider a second render system to accompany Mantra and use each based on its respective strengths.
Sorry, no silver bullet in today's deals, but maybe this helps anyway.
Marc
like cpb says, a HIP file for experimentation always is a good idea.
> every time I move the curve it takes a long time to recalculate
… you might consider caching the state of your procedural construction and only recook on the click of a button - have a read on caching results, file caches etc. Because if you *do* recook upon on every input change, you will always run into user experience issues.
Sometimes it makes sense to use proxy geometry / simplified representations for setup purpose and have a switch somewhere that applies what you created with the proxies to the actual “render” geometry. This is more “UXP design” than “procedural thinking”, but with a fully procedural workflow you have to consider both.
On Mantra rendering and speeding it up there are some discussions around here, some tutorials and even one or two masterclasses. In the end, if you want “really fast rendering”, you may have to consider a second render system to accompany Mantra and use each based on its respective strengths.
Sorry, no silver bullet in today's deals, but maybe this helps anyway.
Marc
Technical Discussion » Very slow
- malbrecht
- 806 posts
- Offline
Moin,
could you be a tad more specific about what you mean by “slow”? My wife uses her brain, legs and hand and, at times, is very slow, too. I am quite sure *that* is a configuration problem on her side, yet she keeps insisting it's all my fault.
What are you trying to do? Are you experiencing slowdowns in moving geometry around (H isn't the fastest here) or are you talking about simulations? What kind of simulations? Are you sure you optimized your sim settings? Are you talking about rendering? Mantra isn't “fast” but has some (volumetric-related) advantages fast renderers don't offer out of the box.
If your system is not using SSD but mechanical drives, that might be something to look into (in general anyway ) …
There might be settings to tweak, too, but it really depends on what you are experimenting with and what exactly “slow” is for you.
Marc
could you be a tad more specific about what you mean by “slow”? My wife uses her brain, legs and hand and, at times, is very slow, too. I am quite sure *that* is a configuration problem on her side, yet she keeps insisting it's all my fault.
What are you trying to do? Are you experiencing slowdowns in moving geometry around (H isn't the fastest here) or are you talking about simulations? What kind of simulations? Are you sure you optimized your sim settings? Are you talking about rendering? Mantra isn't “fast” but has some (volumetric-related) advantages fast renderers don't offer out of the box.
If your system is not using SSD but mechanical drives, that might be something to look into (in general anyway ) …
There might be settings to tweak, too, but it really depends on what you are experimenting with and what exactly “slow” is for you.
Marc
-
- Quick Links