Hi,
Thank you VERY MUCH!!
Sorry for the delayed answer, but now I am on a trip…
best
dagush.-
Found 97 posts.
Search results Show results as topic list.
Technical Discussion » Adding Primitive Normals
- dagush
- 98 posts
- Offline
Technical Discussion » Adding Primitive Normals
- dagush
- 98 posts
- Offline
Technical Discussion » Adding Primitive Normals
- dagush
- 98 posts
- Offline
Hi,
I know that probably this has been asked a thousand times, but I cannot find the answer in the forums… I need to explicitly add the primitive normals (for later use) to every polygon in a scene. In the attached file, I can see the prim normals in the frozen null file, but the attribCreate node systematically gives me (0,0,0)… any idea what I am doing wrong?
Sorry for this newbie question!
dagush.-
I know that probably this has been asked a thousand times, but I cannot find the answer in the forums… I need to explicitly add the primitive normals (for later use) to every polygon in a scene. In the attached file, I can see the prim normals in the frozen null file, but the attribCreate node systematically gives me (0,0,0)… any idea what I am doing wrong?
Sorry for this newbie question!
dagush.-
Technical Discussion » Weird 12.5 hscript problem: Something changed from 12.1...
- dagush
- 98 posts
- Offline
Dear Tamte,
THANK YOU VERY MUCH!!!
In the end, it was only the $PR. The curious part is that this code was working since ver 10 or something similar…
in any case, thanks!!!
dagush.-
THANK YOU VERY MUCH!!!
In the end, it was only the $PR. The curious part is that this code was working since ver 10 or something similar…
in any case, thanks!!!
dagush.-
Technical Discussion » Weird 12.5 hscript problem: Something changed from 12.1...
- dagush
- 98 posts
- Offline
Dear all,
I've stumbled upon a very strange behavioural problem the normal(….) hscript expression stopped working from ver 12.1 to 12.5. Basically, in a transform node, in the “ry” channel, I put
acos(normal('../each1',$PR,0.5,0.5,2))
however, in 12.5 this always displays 0, when it should show something different (135 in the attached example). The weirdest thing is that it DOES the right rotation, it only SHOWS a bad value!!!
In my old 12.1.125 version, it works without problem. however, in my new 12.5.376 version, it refuses to do its job, and that's affecting my whole pipeline… (you cannot ch(…) it anymore…)
I hope you can help me, or at least tell me if this is a knwon issue…
thanks!!!!
dagush.-
I've stumbled upon a very strange behavioural problem the normal(….) hscript expression stopped working from ver 12.1 to 12.5. Basically, in a transform node, in the “ry” channel, I put
acos(normal('../each1',$PR,0.5,0.5,2))
however, in 12.5 this always displays 0, when it should show something different (135 in the attached example). The weirdest thing is that it DOES the right rotation, it only SHOWS a bad value!!!
In my old 12.1.125 version, it works without problem. however, in my new 12.5.376 version, it refuses to do its job, and that's affecting my whole pipeline… (you cannot ch(…) it anymore…)
I hope you can help me, or at least tell me if this is a knwon issue…
thanks!!!!
dagush.-
Houdini Lounge » Happy 2013
- dagush
- 98 posts
- Offline
Dear all,
We just want to thank you your many useful answers and all the help you gave us in the past, and certainly in the future!!!
Please, have a (late) merry Christmass and a Happy New Year!!!
gus.-
We just want to thank you your many useful answers and all the help you gave us in the past, and certainly in the future!!!
Please, have a (late) merry Christmass and a Happy New Year!!!
gus.-
Technical Discussion » Problem with foreach prim and uvquickshade...
- dagush
- 98 posts
- Offline
Thank you VERY MUCH!
I did not know how to link with the rendering part, but this was awesome!
Thanks!!
gus.-
I did not know how to link with the rendering part, but this was awesome!
Thanks!!
gus.-
Technical Discussion » Problem with foreach prim and uvquickshade...
- dagush
- 98 posts
- Offline
Hi,
Thank you very much for your answer, but I must confess I am not following your explanation. I tried to follow these steps, and create a SHOP with texture override, but I really do not know how to pass information from the primitive (remember that the name of the texture to load is built from attributes at the primitive level) to the SHOP. All I get are “nonetype has no attribute…”, that is logical as I am tying to access a node geometry, which is not available here…
The other option is not possible, as the whole idea is to avoid creating one material for each texture, as we have one texture for each primitive! The idea was to have something VERY compact, so I invented the uvquickshade-inside-foreach trick.
By the way, I also changed the foreach-prim node by a partition + foreach-group combination, with the same results. Now I am starting to think that the problem is that Houdini believes this node does not need to be recooked for each primitive, and only evaluates it once. I've checked and the textures names that get generated are different and correct, but for some weird reason they are not evaluated. for instance, I disconnect the wire from the geometry into the foreach, I wire it again, and no evaluations are performed (I have a print inside the Python code to generate the name). This means that Houdini is not evaluating the node!
Please, help me as I have no clue where to go from here…
Thanks!!!
dagush.-
Thank you very much for your answer, but I must confess I am not following your explanation. I tried to follow these steps, and create a SHOP with texture override, but I really do not know how to pass information from the primitive (remember that the name of the texture to load is built from attributes at the primitive level) to the SHOP. All I get are “nonetype has no attribute…”, that is logical as I am tying to access a node geometry, which is not available here…
The other option is not possible, as the whole idea is to avoid creating one material for each texture, as we have one texture for each primitive! The idea was to have something VERY compact, so I invented the uvquickshade-inside-foreach trick.
By the way, I also changed the foreach-prim node by a partition + foreach-group combination, with the same results. Now I am starting to think that the problem is that Houdini believes this node does not need to be recooked for each primitive, and only evaluates it once. I've checked and the textures names that get generated are different and correct, but for some weird reason they are not evaluated. for instance, I disconnect the wire from the geometry into the foreach, I wire it again, and no evaluations are performed (I have a print inside the Python code to generate the name). This means that Houdini is not evaluating the node!
Please, help me as I have no clue where to go from here…
Thanks!!!
dagush.-
Technical Discussion » Problem with foreach prim and uvquickshade...
- dagush
- 98 posts
- Offline
Dear friends,
For a project I am developing, I've been struggling with some apparently simple Houdini nodes and some straightforward Python code, but I cannot find not only what the bug is, but also how the foreach-prim works.
I want to texture a model, but using a different textures for each primitive. Each primitive carries, as attributes, the information needed to texture it. To simplify explanations, I've created a locked node that contains all information from the upstream network, which is not important for this problem. Then, as the primitives I am using are simple flat rectangles, I've decided to texture them with a uvquickshade node. It's simple, it's easy and I think it's elegant. However, I could not put my code in the Texture Map parm of the uvquickshade, so I decided to put this node inside a foreach node, with the “For” parm set to “Each Primitive/Point”. So, we have an outer foreach-primitive loop with a simple uvquickshade node inside, and the quickshade node selects the texture based on some informaton attached to the primitives as attributes. Simple, I think.
Problems are
1- I added a print statement inside the code for the uvquickshade, and the printed text only appears 3 or four times for each cook, even if I disconnect and connect the foreach node again. There are 18 input primitives, but sometimes I do not get even a single print!!!! How's that even possible? For me, it is obvious that I am not using the foreach-primitive node correctly…
2- Some stupid tests I did showed that the uvquickshade almost never loads the right texture, but sometimes it loads ONE (and the same) texture for every primitive! That means that, somehow, every primitive is “the same” and one evaluation of the uvquickshade is used for all the primitives. I guess my problem here is the same as in the previous point, but I wanted to be sure.
3- Right now, the code inside the uvquickshade appends ‘$HIP/“ to build the texture name, but in some tests I did I got nothing until I appended hou.expandString(’$HIP'), which is weird to me. Why using $HIP doesn't work, and I have to expand it? In any case, this is a minnor issue, as the foreach problem is preventing me from moving forward…
I attach a demo file, reduced to its bare minimum, plus some textures to try. By the way, some primitives do not have an associated texture, so showing them ”as is" is OK.
thank you VERY MUCH!!!!
dagush.-
For a project I am developing, I've been struggling with some apparently simple Houdini nodes and some straightforward Python code, but I cannot find not only what the bug is, but also how the foreach-prim works.
I want to texture a model, but using a different textures for each primitive. Each primitive carries, as attributes, the information needed to texture it. To simplify explanations, I've created a locked node that contains all information from the upstream network, which is not important for this problem. Then, as the primitives I am using are simple flat rectangles, I've decided to texture them with a uvquickshade node. It's simple, it's easy and I think it's elegant. However, I could not put my code in the Texture Map parm of the uvquickshade, so I decided to put this node inside a foreach node, with the “For” parm set to “Each Primitive/Point”. So, we have an outer foreach-primitive loop with a simple uvquickshade node inside, and the quickshade node selects the texture based on some informaton attached to the primitives as attributes. Simple, I think.
Problems are
1- I added a print statement inside the code for the uvquickshade, and the printed text only appears 3 or four times for each cook, even if I disconnect and connect the foreach node again. There are 18 input primitives, but sometimes I do not get even a single print!!!! How's that even possible? For me, it is obvious that I am not using the foreach-primitive node correctly…
2- Some stupid tests I did showed that the uvquickshade almost never loads the right texture, but sometimes it loads ONE (and the same) texture for every primitive! That means that, somehow, every primitive is “the same” and one evaluation of the uvquickshade is used for all the primitives. I guess my problem here is the same as in the previous point, but I wanted to be sure.
3- Right now, the code inside the uvquickshade appends ‘$HIP/“ to build the texture name, but in some tests I did I got nothing until I appended hou.expandString(’$HIP'), which is weird to me. Why using $HIP doesn't work, and I have to expand it? In any case, this is a minnor issue, as the foreach problem is preventing me from moving forward…
I attach a demo file, reduced to its bare minimum, plus some textures to try. By the way, some primitives do not have an associated texture, so showing them ”as is" is OK.
thank you VERY MUCH!!!!
dagush.-
Technical Discussion » Houdini and JPype
- dagush
- 98 posts
- Offline
Dear all,
We are trying to add some new functionality to Houdini that was developed by someone else in Java. After a little search, we decided to use the JPype library. We managed to control the Java code from the regular python (not Houdini's) and get our stuff done. Now, we are trying to incorporate this into a Python SOP, but when we try to do it from the python shell we get an “import error DLL load failed” on Windows and an “ImportError No module named _jpype” on Mac Os X. When we execute the same code with Houdini's own python distribution, but outside the Houdini environment (you know, doing “python” at the prompt), we get it right. So, we are quite sure it must be something between Houdini itself and the JPype .dll or .so, because Houdini's own Python does accept the code.
Do you have any clue about how to do it?
Thanks in advance!!!
best regards
dagush.-
We are trying to add some new functionality to Houdini that was developed by someone else in Java. After a little search, we decided to use the JPype library. We managed to control the Java code from the regular python (not Houdini's) and get our stuff done. Now, we are trying to incorporate this into a Python SOP, but when we try to do it from the python shell we get an “import error DLL load failed” on Windows and an “ImportError No module named _jpype” on Mac Os X. When we execute the same code with Houdini's own python distribution, but outside the Houdini environment (you know, doing “python” at the prompt), we get it right. So, we are quite sure it must be something between Houdini itself and the JPype .dll or .so, because Houdini's own Python does accept the code.
Do you have any clue about how to do it?
Thanks in advance!!!
best regards
dagush.-
Technical Discussion » Versioning problems
- dagush
- 98 posts
- Offline
Dear all,
I've stumbled with a VERY weird HDA versioning problem. Basically, I created a (quite complex) scene with an HDA, and I saved the HDA in its respective OTL. This HDA had regular nodes, some of which had Python code embedded for their parms. After that, for other projects, I re-used, extended and updated the HDA. When I returned to load the original scene, I've found that the python code that was inside some node parameters in the HDA did not update with the HDA itself. However, the weird part is that the parameters of the HDA interface DID update, but the internal python code didn't… So, I now get errors in the Python execution in the parameters because the hou.pwd().parm('xxxx') pices of code are not working any more, as parm xxxx does not exist any more…
It looks like, somehow, the old code remains at the .hip file, but Houdini is taking the other elements, like the parameter interface, from the OTL file. I find this mixture quite disturbing…
Any ideas? Have you experienced something similar? Any way to avoid this situation?
Thanks in advance!
yours
dagush.-
I've stumbled with a VERY weird HDA versioning problem. Basically, I created a (quite complex) scene with an HDA, and I saved the HDA in its respective OTL. This HDA had regular nodes, some of which had Python code embedded for their parms. After that, for other projects, I re-used, extended and updated the HDA. When I returned to load the original scene, I've found that the python code that was inside some node parameters in the HDA did not update with the HDA itself. However, the weird part is that the parameters of the HDA interface DID update, but the internal python code didn't… So, I now get errors in the Python execution in the parameters because the hou.pwd().parm('xxxx') pices of code are not working any more, as parm xxxx does not exist any more…
It looks like, somehow, the old code remains at the .hip file, but Houdini is taking the other elements, like the parameter interface, from the OTL file. I find this mixture quite disturbing…
Any ideas? Have you experienced something similar? Any way to avoid this situation?
Thanks in advance!
yours
dagush.-
Technical Discussion » Freezing cooking while manipulating the network with Python
- dagush
- 98 posts
- Offline
Dear Edward,
Than you very much! I'll look at that module as soon as possible, but it looks as the PERFECT solution!
Thanks!
dagush.-
Than you very much! I'll look at that module as soon as possible, but it looks as the PERFECT solution!
Thanks!
dagush.-
Technical Discussion » Iterating of groups with Python SOP
- dagush
- 98 posts
- Offline
Hi,
Probably with a regular expression (re)? Have a look at
http//docs.python.org/library/re.html
and use that instead of (string.find(groupmask) == 0) that you're actually using… I guess this could work.
best regards
dagush.-
Probably with a regular expression (re)? Have a look at
http//docs.python.org/library/re.html
and use that instead of (string.find(groupmask) == 0) that you're actually using… I guess this could work.
best regards
dagush.-
Technical Discussion » Freezing cooking while manipulating the network with Python
- dagush
- 98 posts
- Offline
Hi,
Thanks for the answer!
I've tested it and it seems to run really fine, so this is a fantastic solution for the “freezing/unfreezing” part.
Now, I still have the timings problem how can I, from Python, know the time that a given step in the process took (in my case, network pre-processing and final cook). As I've mentioned, it seems to me that Houdini runs the Python shell in a separate thread, as the times I'm getting are clearly unrealistic (less than one second for a 35-second cook!).
Any ideas on this part?
Anyway, thanks for the answer! It's THE solution for that part of my problem!
thanks
dagush.-
Thanks for the answer!
I've tested it and it seems to run really fine, so this is a fantastic solution for the “freezing/unfreezing” part.
Now, I still have the timings problem how can I, from Python, know the time that a given step in the process took (in my case, network pre-processing and final cook). As I've mentioned, it seems to me that Houdini runs the Python shell in a separate thread, as the times I'm getting are clearly unrealistic (less than one second for a 35-second cook!).
Any ideas on this part?
Anyway, thanks for the answer! It's THE solution for that part of my problem!
thanks
dagush.-
Technical Discussion » Freezing cooking while manipulating the network with Python
- dagush
- 98 posts
- Offline
Dear All,
I'm running into some problems I do not know how to figure out, and perhaps you can help me, as you usually do. I'm trying to “optimize” my code, disabling all re-computations while I'm manipulating the obj network from Python (inside the Python shell). The “manipulations” I'm referring to include node additions/deletions and/or paramtere changes. so, the idea is to “freeze” Houdini from cooking during a moment, re-shape (manipulate) the network, and after that unfreeze Houdini and let it do its usual work and build the geometry. However, I also need to have timings of the diferent stages. Basically, I need two fundamental timings the graph manipulation stage and the time it took Houdini to re-cook everything.
I've tried with hou.setUpdateMode(hou.updateMode.Manual) to “freeze” and hou.setUpdateMode(hou.updateMode.AutoUpdate) to “unfreeze”, and the time library to show the timings (with time.clock or time.time depending on the OS). However, the results for the cooking step seem unrealistic I get just 1.07 seconds while I've seen Houdini cooking for at least 30 seconds or more (and I may have re-computations that take up to 20 minutes!!!). My feeling is that it is not the time library, but Houdini returning control to the library even when it is still cooking… are they separate threads?
So… any ideas? How can I get precise timings for these two stages? Am I correctly freezing Houdini, or am I wrong with respect to this, too?
any help will be GREATLY appreciated!
thanks a lot
dagush.-
I'm running into some problems I do not know how to figure out, and perhaps you can help me, as you usually do. I'm trying to “optimize” my code, disabling all re-computations while I'm manipulating the obj network from Python (inside the Python shell). The “manipulations” I'm referring to include node additions/deletions and/or paramtere changes. so, the idea is to “freeze” Houdini from cooking during a moment, re-shape (manipulate) the network, and after that unfreeze Houdini and let it do its usual work and build the geometry. However, I also need to have timings of the diferent stages. Basically, I need two fundamental timings the graph manipulation stage and the time it took Houdini to re-cook everything.
I've tried with hou.setUpdateMode(hou.updateMode.Manual) to “freeze” and hou.setUpdateMode(hou.updateMode.AutoUpdate) to “unfreeze”, and the time library to show the timings (with time.clock or time.time depending on the OS). However, the results for the cooking step seem unrealistic I get just 1.07 seconds while I've seen Houdini cooking for at least 30 seconds or more (and I may have re-computations that take up to 20 minutes!!!). My feeling is that it is not the time library, but Houdini returning control to the library even when it is still cooking… are they separate threads?
So… any ideas? How can I get precise timings for these two stages? Am I correctly freezing Houdini, or am I wrong with respect to this, too?
any help will be GREATLY appreciated!
thanks a lot
dagush.-
Technical Discussion » Cookie problem?
- dagush
- 98 posts
- Offline
Dear All,
I'm trying to cut a part of a rectangle out from a larger one (basically, these are the floors in a building), but the cookie node I'm using refuses to provide ANY output at all. I've built a small example showing just these two, and I'm attaching it here. Please, bear in mind that this is one facade out of a whole city, so any jittering-based solution will work only for one or two facades, but will certainly fail for others. I need a more “robust” solution… Also, these nodes are inside a foreach loop, which generates the boxes to cut all the floors iteratively…
Is there any good known solution for this simple case?
thanks a lot!!!
dagush.-
I'm trying to cut a part of a rectangle out from a larger one (basically, these are the floors in a building), but the cookie node I'm using refuses to provide ANY output at all. I've built a small example showing just these two, and I'm attaching it here. Please, bear in mind that this is one facade out of a whole city, so any jittering-based solution will work only for one or two facades, but will certainly fail for others. I need a more “robust” solution… Also, these nodes are inside a foreach loop, which generates the boxes to cut all the floors iteratively…
Is there any good known solution for this simple case?
thanks a lot!!!
dagush.-
Technical Discussion » Random file instantiation
- dagush
- 98 posts
- Offline
Dear mrCatfish,
Thanks for your answer! Actually, following from it, I've discovered that the copy-stamp mechanism allows you to do things that you cannot do with a foreach-primitive method. That is, I've done several experiments with and without a ‘stamp’ expression in my nodes, and I've discovered the expression forced the node to re-cook, while without it cooking was performed once or twice for the whole scene!
thanks!!!
best regards
dagush.-
Thanks for your answer! Actually, following from it, I've discovered that the copy-stamp mechanism allows you to do things that you cannot do with a foreach-primitive method. That is, I've done several experiments with and without a ‘stamp’ expression in my nodes, and I've discovered the expression forced the node to re-cook, while without it cooking was performed once or twice for the whole scene!
thanks!!!
best regards
dagush.-
Technical Discussion » Random file instantiation
- dagush
- 98 posts
- Offline
Hello,
Perhaps I'm too tired today, but I've stumbled with a silly problem I cannot figure out how to solve. Basically, I have a set of primitives/points, and I want to load a different asset for each primitive based on a random selection. I also have to do some extra operations (scalings, complex rotations, etc), so I believe cannot use the standard copy node… perhaps I'm wrong on this, too, but I'll leave this for later thoughts.
To illustrate my problem, I've created a dummy demo that uses an object_merge instead of the file asset, a few coloured cubes instead of loaded assets, and a silly copy node to place the cube at the corrsponding point position. As you can see, every time yo force the object_merge to re-cook, it shows a grid of a different color. But what I want is a single grid with a random color distribution on it. I don't care if the distribution changes every time I reload the file or I force the cooking of the nodes, but I do not want a uniform grid!
Is there any way to force the object_merge to re-cook for every primitive/point? I haven't been able to find one…
Any help will be greatly appreciated!!
best regards
dagush.-
Perhaps I'm too tired today, but I've stumbled with a silly problem I cannot figure out how to solve. Basically, I have a set of primitives/points, and I want to load a different asset for each primitive based on a random selection. I also have to do some extra operations (scalings, complex rotations, etc), so I believe cannot use the standard copy node… perhaps I'm wrong on this, too, but I'll leave this for later thoughts.
To illustrate my problem, I've created a dummy demo that uses an object_merge instead of the file asset, a few coloured cubes instead of loaded assets, and a silly copy node to place the cube at the corrsponding point position. As you can see, every time yo force the object_merge to re-cook, it shows a grid of a different color. But what I want is a single grid with a random color distribution on it. I don't care if the distribution changes every time I reload the file or I force the cooking of the nodes, but I do not want a uniform grid!
Is there any way to force the object_merge to re-cook for every primitive/point? I haven't been able to find one…
Any help will be greatly appreciated!!
best regards
dagush.-
Technical Discussion » Problems with PyQt4
- dagush
- 98 posts
- Offline
Dear Edward,
I think we'll probably resort to creating a regular but empty (dummy) HDA, purely for GUI purposes, and perform a node.setSelected() every time the GUI needs to be displayed. In the dummy HDA we'll probably have a button with something like “run” which will have a callback to our main code with the hda itself as parameter. Not very elegant, but definitely cross platform! -)
With respect to the UI script, I've discovered that hou.ui.createDialog() is NOT in the documentation for hou.ui (http//www.sidefx.com/docs/houdini11.0/hom/hou/ui), so I'm wondering how official or stable it is. Anyway, after a lot of guessing I managed to open a silly script window with
d = hou.ui.createDialog(“path/test.ui”)
where test.ui is the attached file. I'm posting it here just for illustrative purposes, just in case anyone wants to try. I think it's a VERY interesting way to create custom dialogs. Now, I only need to understand the docs at
http//www.sidefx.com/docs/hdk11.0/hdk_uinative_uiscript.html
which are a bit hard to start with. There aren't any other docs, right? ;-)
Anyway, we'll probably stick to the dummy HDA GUI node, which seems like a more lasting solution.
Thanks a lot for all your help!!!
regards
dagush.-
I think we'll probably resort to creating a regular but empty (dummy) HDA, purely for GUI purposes, and perform a node.setSelected() every time the GUI needs to be displayed. In the dummy HDA we'll probably have a button with something like “run” which will have a callback to our main code with the hda itself as parameter. Not very elegant, but definitely cross platform! -)
With respect to the UI script, I've discovered that hou.ui.createDialog() is NOT in the documentation for hou.ui (http//www.sidefx.com/docs/houdini11.0/hom/hou/ui), so I'm wondering how official or stable it is. Anyway, after a lot of guessing I managed to open a silly script window with
d = hou.ui.createDialog(“path/test.ui”)
where test.ui is the attached file. I'm posting it here just for illustrative purposes, just in case anyone wants to try. I think it's a VERY interesting way to create custom dialogs. Now, I only need to understand the docs at
http//www.sidefx.com/docs/hdk11.0/hdk_uinative_uiscript.html
which are a bit hard to start with. There aren't any other docs, right? ;-)
Anyway, we'll probably stick to the dummy HDA GUI node, which seems like a more lasting solution.
Thanks a lot for all your help!!!
regards
dagush.-
Technical Discussion » Problems with PyQt4
- dagush
- 98 posts
- Offline
That would be great!!!
However, for our project, we'll have to find a workaround to keep going… We'll see…
best regards and thanks for your help, graham!!!!
dagush.-
However, for our project, we'll have to find a workaround to keep going… We'll see…
best regards and thanks for your help, graham!!!!
dagush.-
-
- Quick Links