Yes, it's an application that ships as part of Cygwin. So that “if” statement is meant to detect if cygwin is installed, and do some cygwin-specific stuff if it is. I'm not sure why your tcsh would not accept the -f syntax, it's pretty standard. Are you definitely running tcsh as your shell, not sh or some other variant? You can also try running the csh that ships with Houdini. The houdini_setup script works fine with it.
Mark
Found 1020 posts.
Search results Show results as topic list.
Technical Discussion » CYGPATH in houdini_setup
- mtucker
- 4438 posts
- Offline
Technical Discussion » Create new subnet operator in houdini 7 ?
- mtucker
- 4438 posts
- Offline
From the File menu, choose “New Operator Type…”. Though it is almost always easiest to put down a SubNetwork operator in your network, and choose “Create Type From…” from the right mouse menu of that SubNetwork.
Mark
Mark
Technical Discussion » Point Groups
- mtucker
- 4438 posts
- Offline
The function “setEntries” (called in the second last line of your loop) adds all points in the GU_Detail to the group. I'm not sure what you thought this function was for, but clearly there was some confusion on this point
Mark
Mark
Technical Discussion » Presets in OTLs
- mtucker
- 4438 posts
- Offline
Just to expand on the regular presets facility… If you create a bunch of presets for your digital asset, you'll end up with a file called $HH/presets/Object/myasset.idx, or something similar. This is the file that contains all the preset definitions you have saved. Find this file and remember where it is. Now open the Operator Type Manager and find the definition of your asset. Right-click on it and choose “Edit Contents…”. On the left is a list of “sections” that make up your digital asset definition. Below that list is a spot to enter the name of a file. Use the Plus button to open up a file browser and find the .idx file containing your presets. The “Section Name” will be set to the name of the .idx file. Change the Section Name to “Presets”. Hit the Add File button. Hit Accept. Now those presets are stored with the digital asset.
This ability to store presets directly in a digital asset definition isn't well advertised because it is far from being an automatic process. Updating that Presets section requires saving it out to the .idx file, adding or editing the presets in that external file, then re-adding the .idx file using the Edit Contents dialog. It's not pretty, but it can be a very useful feature.
Mark
This ability to store presets directly in a digital asset definition isn't well advertised because it is far from being an automatic process. Updating that Presets section requires saving it out to the .idx file, adding or editing the presets in that external file, then re-adding the .idx file using the Edit Contents dialog. It's not pretty, but it can be a very useful feature.
Mark
Technical Discussion » Choose operator dialog
- mtucker
- 4438 posts
- Offline
Try:
#pragma hint <parmname> oppath <optype>
Where <parmname> is the name of your parameter, and <optype> is “sop”, or “pop”, or “obj/geo”… A complete list of available optype values is in the VEX compiler documentation unter the “hint” pargma.
Mark
#pragma hint <parmname> oppath <optype>
Where <parmname> is the name of your parameter, and <optype> is “sop”, or “pop”, or “obj/geo”… A complete list of available optype values is in the VEX compiler documentation unter the “hint” pargma.
Mark
Technical Discussion » killing a long cook
- mtucker
- 4438 posts
- Offline
Esc is your best option. Sometimes you have to hit it a few times because Houdini may interrupt one cook and then start another (depending on the situation). I usually just hit Esc repeatedly until all cooking stops. There are probably some cases where this still won't interrupt the cook instantly, but you can usually get control back in a few seconds.
Mark
Mark
Technical Discussion » hotl in hscript?
- mtucker
- 4438 posts
- Offline
If you can wait until 6.5 is released, don't bother spending too much time on those parsing routines… otls will let you specify exactly what data to output and in what order, without the labels. But please don't ask me when 6.5 is going to be released…
Mark
Mark
Technical Discussion » Vops textures need individual uv layers?
- mtucker
- 4438 posts
- Offline
Just to be perfectly clear: the reason there is a problem when you have two shading layer VOPs both set to output layer 1 is that there is a bug in the shading layer VOP. It will be fixed in the next major release. For now you'll have to get by using a single shading layer VOP and piping its output to multiple locations. Thanks for finding this one,
Mark
Mark
Technical Discussion » How to make particles flow along a spline? Old question.
- mtucker
- 4438 posts
- Offline
This method does everything within POPs. It is quite similar to the sweep/creep method:
1. Start Houdini, and delete all objects.
2. Create three geometry objects, “source”, “path”, and “particles”. Delete all the default File SOPs.
3. In source, create a circle, in the ZX plane.
4. In path, create a nurbs curve which starts near the centre of the circle and goes wherever.
5. In particles, create a POP Network and dive in.
6. Create a source POP, feeding into an attribute POP, feeding into a Position POP.
7. In the Source POP, set the SOP parameter to “/obj/source/circle1”. Set the Emission Type to “Surfaces (random)”. Set the Birth Group to “newparticles”.
8. In the attribute POP, set the Source Group to “newparticles”, the Name to “startpos”, the Size to “3”, and the Value to “$TX”, “$TY + rand($ID)”, and “$TZ”.
9. Here's the slightly ugly part. In the Position POP, enter the following expressions for Position (note we are on the “Position” page, not the “Path” page:
$STARTPOS1 + primuv(“/obj/path/curve1”, 0, “P”, 0, $AGE/10, 0)
$STARTPOS2 + primuv(“/obj/path/curve1”, 0, “P”, 1, $AGE/10, 0)
$STARTPOS3 + primuv(“/obj/path/curve1”, 0, “P”, 2, $AGE/10, 0)
Tada! Particles following a path. Play with the “$AGE/10” value to specify the rate at which the particles move. You may also want to resample your curve if necessary (so the particles travel at a roughly constant speed). You can also introduce some noise into the the “$AGE/10” (something like “$AGE/(10+rand($ID)”) to have each particle move at a slightly different rate.
Also this method does not currently calculate velocity. You can do this either using a Cache SOP at the SOP level or by adding a Velocity POP which sets the velocity to something like:
primuv(“/obj/path/curve1”, 0, “P”, 0, $AGE/10, 0) -
primuv(“/obj/path/curve1”, 0, “P”, 0, ($AGE - 1/$FPS)/10, 0)
But if you do that you may also want to add a state POP to set the particles to be “Stopped” so that the POP system won't move the particles according to this velocity (because your Position POP puts them exactly where you want them already).
Mark
1. Start Houdini, and delete all objects.
2. Create three geometry objects, “source”, “path”, and “particles”. Delete all the default File SOPs.
3. In source, create a circle, in the ZX plane.
4. In path, create a nurbs curve which starts near the centre of the circle and goes wherever.
5. In particles, create a POP Network and dive in.
6. Create a source POP, feeding into an attribute POP, feeding into a Position POP.
7. In the Source POP, set the SOP parameter to “/obj/source/circle1”. Set the Emission Type to “Surfaces (random)”. Set the Birth Group to “newparticles”.
8. In the attribute POP, set the Source Group to “newparticles”, the Name to “startpos”, the Size to “3”, and the Value to “$TX”, “$TY + rand($ID)”, and “$TZ”.
9. Here's the slightly ugly part. In the Position POP, enter the following expressions for Position (note we are on the “Position” page, not the “Path” page:
$STARTPOS1 + primuv(“/obj/path/curve1”, 0, “P”, 0, $AGE/10, 0)
$STARTPOS2 + primuv(“/obj/path/curve1”, 0, “P”, 1, $AGE/10, 0)
$STARTPOS3 + primuv(“/obj/path/curve1”, 0, “P”, 2, $AGE/10, 0)
Tada! Particles following a path. Play with the “$AGE/10” value to specify the rate at which the particles move. You may also want to resample your curve if necessary (so the particles travel at a roughly constant speed). You can also introduce some noise into the the “$AGE/10” (something like “$AGE/(10+rand($ID)”) to have each particle move at a slightly different rate.
Also this method does not currently calculate velocity. You can do this either using a Cache SOP at the SOP level or by adding a Velocity POP which sets the velocity to something like:
primuv(“/obj/path/curve1”, 0, “P”, 0, $AGE/10, 0) -
primuv(“/obj/path/curve1”, 0, “P”, 0, ($AGE - 1/$FPS)/10, 0)
But if you do that you may also want to add a state POP to set the particles to be “Stopped” so that the POP system won't move the particles according to this velocity (because your Position POP puts them exactly where you want them already).
Mark
Technical Discussion » Shaderball speed with unused subnets
- mtucker
- 4438 posts
- Offline
Mario Marengo
Again; I'm sure there are a tonne of things I'm not taking into account, but I just thought I'd throw it out there…. would something along those lines be just too crazy?
Yes, it would be a little crazy
That's a very cool idea for avoiding recompiles, but I think the implementation would be quite difficult. One problem would be keeping track of all those parameters (there could be thousands of them), keeping them in the right order, etc. Another problem is disabled parameters - do they get passed as parameters or not? And VOP signature parameters, which change which parameters get used in the code and change the data types that get used in the code. And VOPs that use “ifdefs” in their code based on parameter values can't be simulated by passing parameters - they would require recompiles. So you could say that all those things I mention are exceptions which should trigger recompiles, but I think there is no way to know for a given VOP and parameter whether one or more of these conditions applies…
Plus then there are all the internal issues of actually generating the two types of code, generating the shader calls with all the appropriate parameters, etc. And all this work just to reduce the number of recompiles. Again, I would rather just see recompiles being shoved further into background processing so as to prevent them from disrupting the interface.
Mark
Technical Discussion » Shaderball speed with unused subnets
- mtucker
- 4438 posts
- Offline
As you say, this is a case of us wanting to be completely sure that all required code gets put into the shader. So even if they aren't connected to any output, we always generate code for Print VOPs, Inline VOPs, Parameter VOPs, and, as you noticed, subnet VOPs. This last one is mostly because a subnet VOP may contain a Print VOP, or a Parameter VOP, or an Inline VOP. But we could probably do some more work to cut subnet VOPs out of the code generation process if none of these conditions apply.
As for changing a parameter of a VOP causing a recompile, this is because we recompile the network whenever anything changes that might change the code. And pretty much every parameter of every VOP is going to affect the code is one way or another. I'm not sure if there's a particular example you're thinking of where the recompile isn't necessary, but most changes really do require a recompile, so again we're just being safe.
I think perhaps a better solution to both these problems is not to change the recompile behavior, but just to make it less disruptive. The problem isn't that changing a VOP parameter causes a recompile. The problem is that a recompile basically freezes the interface. You can't continue making changes to your VOPs while it recompiles. You have to wait until it's done, then it updates part of the shader ball, then you're able to make another change to a VOP parameter. If the recompile didn't freeze the interface you could just continue your editing of the network, and when you're done and ready to see the results you could stop typing for a while and actually wait for the shader ball to update. Similarly with the first problem, if a recompile didn't disrupt your workflow it wouldn't matter so much that the compile included the code for all the subnets.
Just a thought.
Mark
As for changing a parameter of a VOP causing a recompile, this is because we recompile the network whenever anything changes that might change the code. And pretty much every parameter of every VOP is going to affect the code is one way or another. I'm not sure if there's a particular example you're thinking of where the recompile isn't necessary, but most changes really do require a recompile, so again we're just being safe.
I think perhaps a better solution to both these problems is not to change the recompile behavior, but just to make it less disruptive. The problem isn't that changing a VOP parameter causes a recompile. The problem is that a recompile basically freezes the interface. You can't continue making changes to your VOPs while it recompiles. You have to wait until it's done, then it updates part of the shader ball, then you're able to make another change to a VOP parameter. If the recompile didn't freeze the interface you could just continue your editing of the network, and when you're done and ready to see the results you could stop typing for a while and actually wait for the shader ball to update. Similarly with the first problem, if a recompile didn't disrupt your workflow it wouldn't matter so much that the compile included the code for all the subnets.
Just a thought.
Mark
Technical Discussion » VEX s,t parameter scaling
- mtucker
- 4438 posts
- Offline
You can also see the code for any SHOP by choosing “Type Properties…” from the RMB menu, and going to the VEX Code page. The advantage of this dialog is that you can actually edit the code and your changes will be applied automatically, so you can easily experiment with the existing code.
Mark
Mark
Technical Discussion » A "Roll-Your-Own" VOP Packaging System
- mtucker
- 4438 posts
- Offline
Mario Marengojason_iversen
I was totally thinking of using the ever handy Event scripts for this, absolutely. Of course I have no idea of how to create one from the Outside, but I'm pretty sure some cool trickery with otlexpand could manage that pretty easily. I've made no research into it, but I seriously doubt there is any OTL “api” to attach these event scripts to an operator in an OTL, right?
API? … no. I don't think so. Or maybe “not yet?”
If you have the HDK, there is an API. The FS_IndexFile and OP_OTLLibrary classes are the ones to look at. They aren't really documented in the HTML help, but their interfaces are pretty simple. The “hotl” application is only about 200 lines long, and about 3/4 of that is parsing and error messages and such. So if you find the one-step OTL collapse and expand operations don't give you enough flexibility or control, the HDK provides you with options.
Mark
Technical Discussion » A "Roll-Your-Own" VOP Packaging System
- mtucker
- 4438 posts
- Offline
Mario Marengo
For Mark Tucker (I think): I'd love to hear why underscores in the file names (not in the labels) seem to need to get doubled up: foo_bar :arrow: foo__bar :?:
That's because the “_” characters is used as the “Escape” character when there are illegal characters in the section name. Because there are a number of characters that aren't legal within file names, we had to do some sort of replacement scheme to convert section names into file names. And here it is:
“/” -> “_1”
“\” -> “_2”
“\n” -> “_3”
“\r” -> “_4”
“\t” -> “_5”
“$” -> “_6”
“~” -> “_7”
“_” -> “__”
So if your section name was “f$o b_r”, the automatically generated file name would be “f_6o b__r”.
But of course none of this should really matter to you, since it is only used when we expand an OTL. For collapsing an OTL, that section list file lets you associate any file name you want with any section name you want. So you could do:
file_name “some section name”
If you were to collapse and re-expand this OTL, you'd get a different section list entry, but I assume you always keep your OTLs in expanded form, so this isn't really a problem. But I know how much people like to know the precise internal details, so there they are
Mark
Technical Discussion » Declaring your own global variables in VEX
- mtucker
- 4438 posts
- Offline
xionmark
No, this is VEX code, not C/C++.
There's no passing by reference in VEX … at least not yet.
Actually, I'm pretty sure that _everything_ in VEX is passed by reference. So you can effectively return as many values as you want from your functions.
Mark
Technical Discussion » OTL scope and other questions
- mtucker
- 4438 posts
- Offline
JColdrick
This is probably about me getting my syntax wrong with all the different types floating out there. What I needed to use the “chs()” for, and what didn't work with “!!” was the popup requestors that put in the path to a node. For instance, the light/transform/lookat button. When I pointed the “!!” format to that type of param, it didn't work. I plugged in the chs() and it worked fine, barring the warning when I saved the OTL.
Hmm. The “!!” syntax should work for these types of parameters. It's possible there was a problem with them that has been fixed in 6.1 (I can't replicate any problems). There may also have been problems if you had multiple layers of referencing (/obj/foo/bar/stuff referenced /obj/foo/bar, which reference /obj/foo). If you see this problem again, please post or email me the hip file so I can have a look. But in any case if the chs() approach is working for you, stick with that.
Unable to resolve node. And I suspect that the param you describe is indeed the “lookat object” type param I mentioned earlier.
Just to clarify - it *works* - it just bitches. Although if this isn't kosher I guess I better know now in case it gets busted in a future version…
Yes, what you are doing is perfectly valid, and you can count on it continuing to sork in the future. There is no good reason for Houdini to be bitching. I've fixed this for 6.1.
Thanks for the bugs,
Mark
Technical Discussion » OTL scope and other questions
- mtucker
- 4438 posts
- Offline
The “!!ch()!!” syntax was introduced because we don't support channel references with some parameter types, and to allow the propogation of button presses, and do a couple of other things that OTLs needed to be able to do. It basically a way of doing a channel reference in a parameter that can't do channel references.
I am a bit curious about your assertion that this syntax works for float/integer parms though. Are you just assuming it work? Because it really should only work for string and “ordinal” parameters (buttons, check boxes, and some menus are “ordinals”, which is different from integer menus or animatable integer parameters).
I'm also concerned about your statement that this syntax does not work for string parameters. Could you provide a sample hip file/OTL where this doesn't work?
As for the warning, you are correct that it should not appear. Could you provide the specific text that appears after the parameter name in the warning dialog? Is it “Unable to resolve node”? Are you using the expression in an “Operator Path” type parameter?
Also, what version of Houdini are you using?
Thanks,
Mark
I am a bit curious about your assertion that this syntax works for float/integer parms though. Are you just assuming it work? Because it really should only work for string and “ordinal” parameters (buttons, check boxes, and some menus are “ordinals”, which is different from integer menus or animatable integer parameters).
I'm also concerned about your statement that this syntax does not work for string parameters. Could you provide a sample hip file/OTL where this doesn't work?
As for the warning, you are correct that it should not appear. Could you provide the specific text that appears after the parameter name in the warning dialog? Is it “Unable to resolve node”? Are you using the expression in an “Operator Path” type parameter?
Also, what version of Houdini are you using?
Thanks,
Mark
Technical Discussion » How to compile the .vfl file
- mtucker
- 4438 posts
- Offline
This is because you put the entry in the vex/VEXsop file. This file is where you list all VEX based SOPs. If it is a surface shader you wrote, remove the entry from the vex/VEXsop file, and put it in shop/SHOPsurface. Then it should appear as a SHOP. I'm a little confused by the “-inputs 2” you put in the index file, because SHOPs do not have inputs. I would suggest getting rid of that when you move to the SHOPsurface file.
Mark
Mark
Technical Discussion » shader in an inline VOP
- mtucker
- 4438 posts
- Offline
I may be misunderstanding what you are trying to do, but I think this is exactly what VOPs were designed to do…
But I would recommend strongly against using the inline VOP to import entire shaders (mostly for the problems you describe). If you bring up the RMB menu on any SHOP, VEX SOP, VEX POP, or whatever, you will see a menu item “Create New VOP Type…”. This will take your vfl code and convert it it into a brand new VOP type with inputs for all the parameters of your shader, and outputs of whatever exported parameters or global variables get modified by the shader. Just give it a try using your favorite SHOP.
You can also do this from the command line, using “vcc -P shader.vfl” will output a dialog script to define a VOP operator type using the code in shader.vfl. There are several related options described in the vcc usage message (“vcc -”). And of course all of this supports OTLs in version 6. Is this what you were trying to do?
Mark
But I would recommend strongly against using the inline VOP to import entire shaders (mostly for the problems you describe). If you bring up the RMB menu on any SHOP, VEX SOP, VEX POP, or whatever, you will see a menu item “Create New VOP Type…”. This will take your vfl code and convert it it into a brand new VOP type with inputs for all the parameters of your shader, and outputs of whatever exported parameters or global variables get modified by the shader. Just give it a try using your favorite SHOP.
You can also do this from the command line, using “vcc -P shader.vfl” will output a dialog script to define a VOP operator type using the code in shader.vfl. There are several related options described in the vcc usage message (“vcc -”). And of course all of this supports OTLs in version 6. Is this what you were trying to do?
Mark
Technical Discussion » Exporting VEX Chop Operator data into CHOP
- mtucker
- 4438 posts
- Offline
If you look at the parameters for the “VEX Motion and Audio Operator” (aka a CHOP Vopnet), there are parameters for setting the Minimum and Maximum number of inputs. By default both of these values are 1, which means that when you create a CHOP based on this Vopnet it is required to have at least 1 and no more than 1 input. The simple definition of a Generator is an operator that doesn't require any inputs (i.e. it can generate something out of nothing). So if you set the Minimum Inputs parameter to 0, your new CHOP type will appear in the Generators folder. You can also set the Maximum Inputs parameter to 0 if an input connected to the CHOP will be ignored.
I would also like to point out that you don't really need to do the “Save as Context Operator Type” to use your new CHOP type. To see what I mean, create a new CHOP Vopnet. In its parameter dialog, change the “CHOP Type Name” parameter to “My New CHOP”. Then go into a CHOP network, and hit TAB to bring up the toolbar. Type “My”, and lo and behold you can create a CHOP of type “My New CHOP”. There is a live connection between the CHOP and the CHOP Vopnet, so any changes you make to the CHOP Vopnet (usch as adding your Noise VOP, and connecting it to the V Output) will immediately update what your CHOP is doing.
The disadvantage of doing things this way is that “My New CHOP”s can only be created in the hip file where My New CHOP is defined. The step of doing a “Save as context operator type” takes a snapshot of your new CHOP type and saves it to disk so you can use it in any hip file. But you give up the “live connection” that you have with the other approach. Which approach you use depends on the needs of your project.
I hope this helps.
I would also like to point out that you don't really need to do the “Save as Context Operator Type” to use your new CHOP type. To see what I mean, create a new CHOP Vopnet. In its parameter dialog, change the “CHOP Type Name” parameter to “My New CHOP”. Then go into a CHOP network, and hit TAB to bring up the toolbar. Type “My”, and lo and behold you can create a CHOP of type “My New CHOP”. There is a live connection between the CHOP and the CHOP Vopnet, so any changes you make to the CHOP Vopnet (usch as adding your Noise VOP, and connecting it to the V Output) will immediately update what your CHOP is doing.
The disadvantage of doing things this way is that “My New CHOP”s can only be created in the hip file where My New CHOP is defined. The step of doing a “Save as context operator type” takes a snapshot of your new CHOP type and saves it to disk so you can use it in any hip file. But you give up the “live connection” that you have with the other approach. Which approach you use depends on the needs of your project.
I hope this helps.
-
- Quick Links