Sorry, I meant to respond to this earlier. An easier approach than using the No Collider is to simply avoid making all the objects mutual affectors in the first place. Instead create a group for the objects that shouldn't collide, and then create a group that is the rest of the objects (the ones that should collide). Then use an Affector DOP to make the ones that should collide mutual affectors. Attached is a file that shows this. The no_collide_objects group can even change over time (make a separate Group DOP for each time range and use Activation expressions).
I know this doesn't answer your original question of removing a few objects from an existing mutual affector relationship, bu that isn't possible, so it's easiest to avoid making the relationship to begin with.
Mark
Found 1024 posts.
Search results Show results as topic list.
Technical Discussion » Modifying DOP Affectors
- mtucker
- 4444 posts
- Offline
Technical Discussion » determining if an asset is unlocked
- mtucker
- 4444 posts
- Offline
Antoine Durr
OK, I'll try this approach. Is there a way to query the various entries in the TypePropertiesOptions file of the OTL? I saw that an OTL with save-contents-unlocked has the entry:
LockContents := 0;
UnlockOnCreate := 1;
No, I'm afraid there is not. The only way to do this would be to otcontentsave that section somewhere, and look at the file on disk. I actually thought there was a way to query these values using optypeinfo() or optype, but obviously I was mistaken.
If you were interested in doing this in the HDK, writing a custom command or expression function to return this information would be very simple. You just need to call:
node->getOperator()->hasContentsSection();
Or of course you can submit an RFE if the otcontentls and HDK solutions are unsatisfactory.
Mark
Technical Discussion » determining if an asset is unlocked
- mtucker
- 4444 posts
- Offline
I'm not sure if this is what you're asking for (and it's not pretty), but you can use otcontentls to get a list of sections in an HDA definition. If “Contents” or “Contents.gz” appears in that list anywhere, that HDA can be locked (i.e. it means the “Save Contents As Locked” button in the Type Properties dialog is turned on).
Mark
Mark
Houdini Lounge » Unanimated cops recook each frame.
- mtucker
- 4444 posts
- Offline
Very very few bugs in Houdini actually turn out to be OS-specific (as much as people love to blame MS for everything). So please send in any problem files you've got to support, and we can figure out if the problem happens on other platforms for you. It isn't your job to install a new OS just to save us some work
If we can't reproduce it on the systems we have available for testing, then we can start worrying about whether it's an OS-specific issue or not.
Thanks,
Mark
If we can't reproduce it on the systems we have available for testing, then we can start worrying about whether it's an OS-specific issue or not.
Thanks,
Mark
Technical Discussion » RBD Chain with a weight on one end
- mtucker
- 4444 posts
- Offline
There were a number of problems with this file. First, you had the box feeding into a separate RBD Solver than the rest of the chain. When you do that, DOPs treats thos as separate simulations. So it was solving the chain first, with no consideration for the box at all. Then it was solving the box, constraining it to the end of the chain, but completely unable to affect the chain in any way. So that's never going to work. You need all your objects going into a single RBD Solver if you want them al to interact with each other.
Second, once you put al objects through the same solver, the rbdconstraint5 node was setting up a constraint from _every_ link to the box (rather than just the last link). So it's no surprise that the simulation blew up. AS Soon as the objects started to rotate it becomes impossible to maintain all the constraints at the same time (notice the white lines that appear, indicating the distance between the actual position of the constraint and its goal). Also, that constraint was set up with a different position than rbdconstraint4. So again when the objects start to rotate, it's impossible to maintain both rbdconstraint4 and rbdconstraint5 at the same tie, so it blows up. To fix this part, change the Objet Location of rbdconstraint5 to “25”, and the “Object Group” to “link_9”.
At this point the simulation no longer blows up. But there is no gravity being a=pplied to the box. So the chain hangs between the origin and the box, while the box moves only slightly. So you want to add gravity to the box.
Now you hit play and the simulation blows up again. But this time it's simply because the box has a mass of 10,000,000, while the chain links each have a mass of about 3. Change the box density to 0.01 to make the masses a little more consistent.
What you end up with is the attached file. I hope that clears some things up for you.
Mark
Second, once you put al objects through the same solver, the rbdconstraint5 node was setting up a constraint from _every_ link to the box (rather than just the last link). So it's no surprise that the simulation blew up. AS Soon as the objects started to rotate it becomes impossible to maintain all the constraints at the same time (notice the white lines that appear, indicating the distance between the actual position of the constraint and its goal). Also, that constraint was set up with a different position than rbdconstraint4. So again when the objects start to rotate, it's impossible to maintain both rbdconstraint4 and rbdconstraint5 at the same tie, so it blows up. To fix this part, change the Objet Location of rbdconstraint5 to “25”, and the “Object Group” to “link_9”.
At this point the simulation no longer blows up. But there is no gravity being a=pplied to the box. So the chain hangs between the origin and the box, while the box moves only slightly. So you want to add gravity to the box.
Now you hit play and the simulation blows up again. But this time it's simply because the box has a mass of 10,000,000, while the chain links each have a mass of about 3. Change the box density to 0.01 to make the masses a little more consistent.
What you end up with is the attached file. I hope that clears some things up for you.
Mark
Houdini Lounge » Swithing from Maya to Houdini - advices needed
- mtucker
- 4444 posts
- Offline
adrian cruceru
can i blend them together, meaning, can i use rman for some objects and mantra for others? but in the end i have to pas through a ROP …
Mantra can't use Renderman shaders, and renderman can't use mantra shaders. So if you have some renderman shaders and some mantra shaders, the only way to have them both appear in the same scene is doing separate renders and compositing. Which of course doesn't let you do proper reflections or global illumination. But Renderman and and VEX are quite similar, so it's no that hard to translate a shader from one language to the other (or so I've heard…)
adrian crucerumtucker
So what about VOPs? VOPs are just a different way to define a SHOP type. Or, more precisely, they are a way to generate VEX code using a GUI (VEX code is used by Houdini for shaders, but can also be used to write SOP types, POP types, CHOP types, and COP types).
should i guess that VEX is like a c code ready to be compiled for whatever i need then?
Yes, you can think of it that way. It is nowhere near as general-purpose as C, but it's enough to let you do some amazing things.
adrian crucerumtucker
So a VOP Network defines a SHOP type. If you create a VOP Network of type VEX Surface Shader (even VOP Networks, which define new node types, have a node type of their own) called newglass, with the SHOP Type Name New Glass, then you have defined a new SHOP type called New Glass. You can now create 10 SHOPs of type New Glass. As you modfy the contents of the VOP Network, all the SHOP instances will change their behavior to match the new VEX code that the VOP Network is generating.
that's very interesting, looks like file referencing but in the same file, kind of clone of a node
I'm not sure I follow you here…? It could just be an issue of terminology, but you aren't cloning a node, you are defining a new _type_ of node. Or maybe you mean the same thing?
adrian cruceru
does it run slower than using API to write plugins?
VEX is generally very very fast. It uses a lot of optimized SIMD assembler code. So if you're just blasting through all the points on some geometry modifying the color attribute, you'd have to work pretty hard to write faster C code. But what VEX lacks is flexibility. You can't add new points to your geometry, or process primitives. But again, it's enough to let you do some amazing things.
I expect there are lots of good tutorials and examples floating around on odforce and the Houdini Exchange if you want to learn more about VEX.
Mark
Houdini Lounge » Swithing from Maya to Houdini - advices needed
- mtucker
- 4444 posts
- Offline
I'll see if I can help clea rup the VOP/SHOP thing a bit. Apologies if I get too basic at some points, but I'd rather give too much informatino than to little. So here goes:
Every node you put down in Houdini has a “type”. The individual nodes are instances of this “type”. So for example you can have 15 Grid SOPs. These are 15 instances of the Grid SOP type. Each instance can then be controlled through the parameters of that instance (to make the grid bigger, change the number of divisions, etc).
This is true in SHOPs as well. You can put down 10 Glass SHOPs, which means you have 10 instances of the Glass SHOP type. Each one has a set of parameters you can control to change the glass color, opacity, etc.
You can think of SHOPs as materials, or more generally as nodes that control your render (a SHOP can be a surface material, a displacement shader, etc). Each SHOP type is associated with a particular renderer. So there are Renderman SHOPs and Mantra SHOPs and MentalRay SHOPs. The reason each SHOP type has to be associated with a particular renderer is that the SHOP type is “defined” by a piece of shader code. Renderman SHOPs are defined by shader code written in the Renderman shading language. Mantra SHOPs are defined by shader code written in the VEX language. So where are these shaders that define the SHOPs?
For Renderman SHOPs, and for some VEX SHOPs, the shader is just a file on disk. The SHOP type holds the name of the shader file, and passes that to the renderer. The renderer then searches its shader path to find that shader file, and uses that.
So what about VOPs? VOPs are just a different way to define a SHOP type. Or, more precisely, they are a way to generate VEX code using a GUI (VEX code is used by Houdini for shaders, but can also be used to write SOP types, POP types, CHOP types, and COP types). So a VOP Network defines a SHOP type. If you create a VOP Network of type VEX Surface Shader (even VOP Networks, which define new node types, have a node type of their own) called newglass, with the SHOP Type Name New Glass, then you have defined a new SHOP type called New Glass. You can now create 10 SHOPs of type New Glass. As you modfy the contents of the VOP Network, all the SHOP instances will change their behavior to match the new VEX code that the VOP Network is generating.
Because a VOP Network lives inside a hip file, you can only create New Glass SHOPs inside the same hip file where the New Glass VOP Network is. However you can also right-mouse on the VOP Network and choose to “Create New SHOP Type FROM VOP Network”. This will save the VEX code from the VOP Network into an OTL (operator type library, which is a collection of node types). The SHOP type in this OTL can be installed into any hip file, and used without requiring the New Glass VOP Network in the hip file. The advantage to this is that your hip files will be smaller and more efficient, and you can easily change the definition of the New Glass SHOP in all your hip files just by updating the one OTL file. The downside of this aproach is that as you continue to edit the New Glass VOP Network, all the instances of the New Glass SHOP type in other hip files will not immediately be updated. You have to re-save the SHOP type into the OTL.
So to summarize, SHOPs are materials that are defined by shader code. VOPs are a tightly integrated graphical environment in Houdini for writing VEX (mantra's shader language) shader code, and by doing so, to define new SHOP types.
To extend a bit on something I mentioned earlier, the VEX languageis not just for shading. You can create a VEX Geometry Operator VOP Network to write VEX code that will define a new SOP type. And all h same rules and methods described above for saving SHOP types to OTLs from VOP Networks also apply to these SOP types.
Anyway, I hope this makes things clearer as opposed to cloudier.
Mark
Every node you put down in Houdini has a “type”. The individual nodes are instances of this “type”. So for example you can have 15 Grid SOPs. These are 15 instances of the Grid SOP type. Each instance can then be controlled through the parameters of that instance (to make the grid bigger, change the number of divisions, etc).
This is true in SHOPs as well. You can put down 10 Glass SHOPs, which means you have 10 instances of the Glass SHOP type. Each one has a set of parameters you can control to change the glass color, opacity, etc.
You can think of SHOPs as materials, or more generally as nodes that control your render (a SHOP can be a surface material, a displacement shader, etc). Each SHOP type is associated with a particular renderer. So there are Renderman SHOPs and Mantra SHOPs and MentalRay SHOPs. The reason each SHOP type has to be associated with a particular renderer is that the SHOP type is “defined” by a piece of shader code. Renderman SHOPs are defined by shader code written in the Renderman shading language. Mantra SHOPs are defined by shader code written in the VEX language. So where are these shaders that define the SHOPs?
For Renderman SHOPs, and for some VEX SHOPs, the shader is just a file on disk. The SHOP type holds the name of the shader file, and passes that to the renderer. The renderer then searches its shader path to find that shader file, and uses that.
So what about VOPs? VOPs are just a different way to define a SHOP type. Or, more precisely, they are a way to generate VEX code using a GUI (VEX code is used by Houdini for shaders, but can also be used to write SOP types, POP types, CHOP types, and COP types). So a VOP Network defines a SHOP type. If you create a VOP Network of type VEX Surface Shader (even VOP Networks, which define new node types, have a node type of their own) called newglass, with the SHOP Type Name New Glass, then you have defined a new SHOP type called New Glass. You can now create 10 SHOPs of type New Glass. As you modfy the contents of the VOP Network, all the SHOP instances will change their behavior to match the new VEX code that the VOP Network is generating.
Because a VOP Network lives inside a hip file, you can only create New Glass SHOPs inside the same hip file where the New Glass VOP Network is. However you can also right-mouse on the VOP Network and choose to “Create New SHOP Type FROM VOP Network”. This will save the VEX code from the VOP Network into an OTL (operator type library, which is a collection of node types). The SHOP type in this OTL can be installed into any hip file, and used without requiring the New Glass VOP Network in the hip file. The advantage to this is that your hip files will be smaller and more efficient, and you can easily change the definition of the New Glass SHOP in all your hip files just by updating the one OTL file. The downside of this aproach is that as you continue to edit the New Glass VOP Network, all the instances of the New Glass SHOP type in other hip files will not immediately be updated. You have to re-save the SHOP type into the OTL.
So to summarize, SHOPs are materials that are defined by shader code. VOPs are a tightly integrated graphical environment in Houdini for writing VEX (mantra's shader language) shader code, and by doing so, to define new SHOP types.
To extend a bit on something I mentioned earlier, the VEX languageis not just for shading. You can create a VEX Geometry Operator VOP Network to write VEX code that will define a new SOP type. And all h same rules and methods described above for saving SHOP types to OTLs from VOP Networks also apply to these SOP types.
Anyway, I hope this makes things clearer as opposed to cloudier.
Mark
Technical Discussion » Viewport not updating in 8.1 DOPs...
- mtucker
- 4444 posts
- Offline
I've never seen a problem like this. Are you sure your simulation is working? You can test this by adding some sort of animating shape to the scene (just put down a sphere with sin($F) as its size). Also, make sure you are using the correct see one/see all settin o nthe viewport (to control whether you are seeing just the current node (the DOP simulation) or all nodes in the scene.
If you still think there is a bug after testing all these things, if you could post a hip file that could help us track it down…
Thanks,
Mark
If you still think there is a bug after testing all these things, if you could post a hip file that could help us track it down…
Thanks,
Mark
Technical Discussion » Kooky math/Vops question - the Rotate VOP
- mtucker
- 4444 posts
- Offline
This latest file is behaving correctly. Your VOP Network will take a point and rotate it around the z axis with the origin as the pivot point. So if you remove the velocity from your points, they don't move because they all start at the origin, and rotating in any way with the origin as the pivot point won't move them. If you move your points out to (1,0,0), but still with no velocity, the points will rotate around the z axis as you expect.
In the hip file as is, the reason the points don't rotate around the origin is their velocity. On each timestep, the POP Network first calculates the new point positions based on the old positions and the velocity. Once ithas done that, it processes the POP nodes in the network. So in your network, at each timestep the particle moves a bit to the right, then that new position is rotated around the z axis with the origin as the pivot point. The path this ends up generating is approximate (though I expect not exactly) a circle, but not centered around the origin. If you do the steps one by one, following a single particle, it makes sense. Move right, then rotate around the z axis. Repeat.
Rotating the velocities in this setup will just make things more confusing. It is not obvious to me what the path would look like in that case. I suppose it would depend on how you rotated the velocities.
As a more general observation of your Vopnets, your methodology of creating a matrix from the particle position, modifying the matrix, and then extracting the translates from the modified matrix seems very odd to me. When doing vector/matrix arithmetic, I find it much easier to build a matrix that represents the transform I want to do, then multiply the vector (position) by the transform matrix. The resulting vector is the transformed position. It's roughly equivalent I guess, but I find it much easier to keep my transform matrix separate from my vectors being transformed. Just from an organizational standpoint. Plus I believe the extract xform operation is considerably slower than simply multiplying a vector by a matrix.
To your original question of how to change the pivot point for your rotations, it's quite easy. Straight rotation matrices will always rotate about the origin (that's why there's no pivot parameter on the rotate VOP). To rotate about a pivot point, first translate your point by the negative of the pivot point (move the pivot to the origin). Then rotate around the origin. Then translate by the pivot point (move the origin back to the pivot point).
I've attached a simple hip file showing the alternate method for transforming points (build the transform matrix, then multiply the position by the transform). It also shows how to rotate around an arbitrary pivot. I've removed all velocity from the particles because (as your hip file demonstrates) velocity can radically affect the motion of a particle when you're altering the position directly. If you are going to be transforming particle velocities as well as positions, remember that to transform a vector properly, you should multiply it by the inverse of the transpose of the transform matrix. Otherwise you're treating the vector (representing a direction and magnitude) like a point (representing position), and you won't like the results.
Mark
In the hip file as is, the reason the points don't rotate around the origin is their velocity. On each timestep, the POP Network first calculates the new point positions based on the old positions and the velocity. Once ithas done that, it processes the POP nodes in the network. So in your network, at each timestep the particle moves a bit to the right, then that new position is rotated around the z axis with the origin as the pivot point. The path this ends up generating is approximate (though I expect not exactly) a circle, but not centered around the origin. If you do the steps one by one, following a single particle, it makes sense. Move right, then rotate around the z axis. Repeat.
Rotating the velocities in this setup will just make things more confusing. It is not obvious to me what the path would look like in that case. I suppose it would depend on how you rotated the velocities.
As a more general observation of your Vopnets, your methodology of creating a matrix from the particle position, modifying the matrix, and then extracting the translates from the modified matrix seems very odd to me. When doing vector/matrix arithmetic, I find it much easier to build a matrix that represents the transform I want to do, then multiply the vector (position) by the transform matrix. The resulting vector is the transformed position. It's roughly equivalent I guess, but I find it much easier to keep my transform matrix separate from my vectors being transformed. Just from an organizational standpoint. Plus I believe the extract xform operation is considerably slower than simply multiplying a vector by a matrix.
To your original question of how to change the pivot point for your rotations, it's quite easy. Straight rotation matrices will always rotate about the origin (that's why there's no pivot parameter on the rotate VOP). To rotate about a pivot point, first translate your point by the negative of the pivot point (move the pivot to the origin). Then rotate around the origin. Then translate by the pivot point (move the origin back to the pivot point).
I've attached a simple hip file showing the alternate method for transforming points (build the transform matrix, then multiply the position by the transform). It also shows how to rotate around an arbitrary pivot. I've removed all velocity from the particles because (as your hip file demonstrates) velocity can radically affect the motion of a particle when you're altering the position directly. If you are going to be transforming particle velocities as well as positions, remember that to transform a vector properly, you should multiply it by the inverse of the transpose of the transform matrix. Otherwise you're treating the vector (representing a direction and magnitude) like a point (representing position), and you won't like the results.
Mark
Technical Discussion » dopfield syntax question
- mtucker
- 4444 posts
- Offline
It would be something like:
dopfield(“/obj/dopnet1”, “clothobject1”, “Constraints/Constraint_clothconstraint1_constraint1/ConRelHard_clothconstraint1_constraint1_1”, “State”, 0, “force”)
You can clean up the “dataname” parameter by going into the Cloth Constraint asset and turning off the “Unique Data Name” toggles, but then you are responsible for ensuring the data names are unique to avoid overwriting.
However, you can also just change your constraint into a Two State Constraint, which automatically does exactly what you are trying to do (makes a hard constraint until a certain force is exceeded, then turns into a spring constraint). You can either just make very weak springs afterthe tear, or you can massage the constraint asset, to transition from a hard constraint to no constraint (instead of to a spring constraint).
Have a look at the “tearing” example file on the Cloth Stitch Constraint help card.
Mark
dopfield(“/obj/dopnet1”, “clothobject1”, “Constraints/Constraint_clothconstraint1_constraint1/ConRelHard_clothconstraint1_constraint1_1”, “State”, 0, “force”)
You can clean up the “dataname” parameter by going into the Cloth Constraint asset and turning off the “Unique Data Name” toggles, but then you are responsible for ensuring the data names are unique to avoid overwriting.
However, you can also just change your constraint into a Two State Constraint, which automatically does exactly what you are trying to do (makes a hard constraint until a certain force is exceeded, then turns into a spring constraint). You can either just make very weak springs afterthe tear, or you can massage the constraint asset, to transition from a hard constraint to no constraint (instead of to a spring constraint).
Have a look at the “tearing” example file on the Cloth Stitch Constraint help card.
Mark
Technical Discussion » DOPs: basic sphere SDF
- mtucker
- 4444 posts
- Offline
One very important point here (the only point Craig is missing, I think) is that the collision guide geometry (the red polygonal representation of the SDF) is simply that - a polygonalization of the SDF. The RBD solver uses the SDF directly, not the polygonalization of the SDF, to do collision detection. So when you say “implicit sphere”, the SDF representation is a precise sphere. The polygonalization loses the prefectness of the sphere, but the RBD solver uses the perfect sphere for collision detection. Even when you use the Ray Intersect method, the rd polygonalization is only an approximation of the SDF. There is more information in the SDF than what can be described by a polygonal surface, and the RBD solver uses all the SDF information, not just the polygonal surface approximation of the SDF.
The culling method is separate from he actual collision detection. It is used to more quickly decide which pairs of objects to do real collision detection with. So when the documentation refers to false positives in the culling phase, that just means the solver will do more collision detection tests than it would if you used the bounding box culling method (if your objects are better approximated as boxes). Thosecollision detection test will then fail to find any collisions, so the end result will not be affected (it just may be a bit slower than if you used bounding box culling).
Mark
The culling method is separate from he actual collision detection. It is used to more quickly decide which pairs of objects to do real collision detection with. So when the documentation refers to false positives in the culling phase, that just means the solver will do more collision detection tests than it would if you used the bounding box culling method (if your objects are better approximated as boxes). Thosecollision detection test will then fail to find any collisions, so the end result will not be affected (it just may be a bit slower than if you used bounding box culling).
Mark
Houdini Lounge » RFE: PARMmenu
- mtucker
- 4444 posts
- Offline
Good idea. RFE added. I also suggested that you may want to be able to add a menu item to a specific parameter on a specific operator type, rather than having the menu items always based on the parameter type. Let me know if you think that's a pointless addition.
Mark
Mark
Technical Discussion » Microsoft Visual C++ Toolkit 2003 and the HDK
- mtucker
- 4444 posts
- Offline
I'm afraid I don't know that for sure. I was just addressing the problem at hand (I've seen those error messages before, and I'm pretty sure it's an MSVCDir problem). I didn't even realize the free version was any different than the real version… I expect if they were going to handicap the free version they would limit the GUI tools, not the command-line stuff (which is all you need for the HDK). Hopefully le_monkey_butt will let us know if the free version works or not. Or perhaps there is someone else out there who knows for sure?
Mark
Mark
Technical Discussion » Microsoft Visual C++ Toolkit 2003 and the HDK
- mtucker
- 4444 posts
- Offline
It looks like the MSVCDir environment variable is set to something like “CProgram Files/Microsoft Visual C++ Toolkit 2003”. Change that value to the 8.3 format path (to get rid of the spaces). So something like “cprogra~1/micros~1”. That should fix it.
Mark
Mark
Houdini Lounge » RBD Object not interacting
- mtucker
- 4444 posts
- Offline
I'm not sure I understand what you're asking, but are you refering to problems with RBD objects jittering when they are sitting on the ground plane? If so, have a look at the “freezing” RBD demos which can be found on the help cards for the Script Solver and the Active Value DOP.
Mark
Mark
Houdini Lounge » RBD Object not interacting
- mtucker
- 4444 posts
- Offline
Is the volume representation for the plank object reasonably accurate? Turn on the “Show Collision Guide Geometry” option on the Collisions page of the plank DOP to check this. If not, try turning up the number of divisions, or model the plank aligned with the x, y, or z axis (volumes are computed as axis-aligned voxel arrays). You should also make sure that your plank is thick enough to be resolved into a valid volume representation (i.e. the plank should not be a single four sided polygon, but should be a cube with a resonable thickness).
Also make sure that the plank object is merged with the domino objects before feeding _all_ the objects into the RBD Solver DOP. This makes sure all the objects are solved by the same solver, and that all objects will affect all other objects.
If none of this works, please post your file. It will make it much easier to figure out what the problem is…
Mark
Also make sure that the plank object is merged with the domino objects before feeding _all_ the objects into the RBD Solver DOP. This makes sure all the objects are solved by the same solver, and that all objects will affect all other objects.
If none of this works, please post your file. It will make it much easier to figure out what the problem is…
Mark
Technical Discussion » DOPs: Point force or Metaball force, how?
- mtucker
- 4444 posts
- Offline
If you want each point on the curve to only influence objects within a certain radius of that point, I'd suggest a Field Force DOP (which does have a couple of example files on the help card). The approach above will apply forces from all points to all objects. Using the Magnet Force DOP will always create a force along the gradient of the metaball, and so won't let you direct the force along the curve.
An RFE has been added to provide a DOP force that is equivalent to the Attractor POP or the Force input on aParticle SOP.
Mark
An RFE has been added to provide a DOP force that is equivalent to the Attractor POP or the Force input on aParticle SOP.
Mark
Technical Discussion » RFE: scroll bar stays put in Details View
- mtucker
- 4444 posts
- Offline
Hmm.. wasn't aware of that.. But i just did this and it was fine.. Simple RBD Object->Gravity->RBDSolver->Merge with ground plane.. Data name for solver was set to “foo” and nothing seemed to break.. Unless I'm missing something..
How did you set the Data Name of the RBD Solver to “foo”? When I do this setup, the Data Name parameter is disabled. The reason it is disabled is because the value in the parameter is ignored, and “Solver” is always used when the input to the Solver DOP is an object stream (grey instead of green). The Data Name on a Solver DOP is only used when you are using an Apply Data DOP to attach the solver to an object, or when you are using the Solver as subdata for another solver. I had actually forgotten about this behavior…
Given this behavior, I may change the defaults as you suggest. But there are still situations (using an Apply Data DOP to attach solver data to an object) where the default of “Solver” makes the most sense. It just depends on which situation is more common…
Mark
Technical Discussion » RFE: scroll bar stays put in Details View
- mtucker
- 4444 posts
- Offline
The issue with the Dtails View scrolling on it's own is already in our database. However if there is a specific value you are monitoring, select that value in the tree view. That value should remain selected and in view even as you play the simulation.
The reason for the name “Solver” on all solvers is that DOPs finds the solver to use for an object by looking for the data named “Solver”. If you attached an RBD Solver to your objects but give it the data name “foo”, your objects won't solve.
I'm not sure what you mean about hunting things down in the details view. What is it that you're trying to find, and how would having a different name for the solver data help? If you are trying to find all objects which are using a particular solver, I would suggest naming your objects so that they give an indication of what solver is being used on them (e.g. the object named clothobject probably has a coth solver attached to it). Would this not accomplish the same thing?
Mark
The reason for the name “Solver” on all solvers is that DOPs finds the solver to use for an object by looking for the data named “Solver”. If you attached an RBD Solver to your objects but give it the data name “foo”, your objects won't solve.
I'm not sure what you mean about hunting things down in the details view. What is it that you're trying to find, and how would having a different name for the solver data help? If you are trying to find all objects which are using a particular solver, I would suggest naming your objects so that they give an indication of what solver is being used on them (e.g. the object named clothobject probably has a coth solver attached to it). Would this not accomplish the same thing?
Mark
Technical Discussion » Dops and windows stability
- mtucker
- 4444 posts
- Offline
There is a bug in DOPs that was introduces in 411 and got fixed in 415. So I'd update your version of Houdini. I tried the procedure you describe and didn't have any problems. Post again if updating versions doesn't fix your problem.
As for Windows stability, I can only speak from my personal experience which is that all significant differences between Windows and Linux stability result from the quality of the specific video drivers you are using. If you have a bad driver under linux, linux will be less stable. If you have a bad driver under Windows, Windows will be less stable. So if you are having lots of problems with crashing under Windows where doing the same things under Linux will not crash, I would suggest looking for at your video driver. The latest driver version is rarely the best one for use with Houdini.
But then I don't work in a real production environment so my observations may not be typical…
Mark
As for Windows stability, I can only speak from my personal experience which is that all significant differences between Windows and Linux stability result from the quality of the specific video drivers you are using. If you have a bad driver under linux, linux will be less stable. If you have a bad driver under Windows, Windows will be less stable. So if you are having lots of problems with crashing under Windows where doing the same things under Linux will not crash, I would suggest looking for at your video driver. The latest driver version is rarely the best one for use with Houdini.
But then I don't work in a real production environment so my observations may not be typical…
Mark
-
- Quick Links