What is the current situation w.r.t. multi-part exr generation in Houdini (mantra, primarily, but others as well)? I can't seem to find any information on using this feature, and it's been a while since OpenExr-2.0…
Preliminary investigations by some Nuke types have seen some significant speedups with the more optimal loading this provides.
Found 10 posts.
Search results Show results as topic list.
Technical Discussion » Multi-part exr?
- Shumberg
- 14 posts
- Offline
Technical Discussion » Can I determine whaat parameter is calling a menu script?
- Shumberg
- 14 posts
- Offline
Technical Discussion » Can I determine whaat parameter is calling a menu script?
- Shumberg
- 14 posts
- Offline
I am running 11.0.469 on Linux. Is this a bug with this version? Can anyone else verify that this works (or doesn't…)?
Technical Discussion » Can I determine whaat parameter is calling a menu script?
- Shumberg
- 14 posts
- Offline
I get an error trying to do tamte's example.
—-
Traceback (most recent call last):
File “<stdin>”, line 2, in expression
NameError: global name ‘kwargs’ is not defined
—-
Traceback (most recent call last):
File “<stdin>”, line 2, in expression
NameError: global name ‘kwargs’ is not defined
Technical Discussion » Can I determine whaat parameter is calling a menu script?
- Shumberg
- 14 posts
- Offline
Please check /out/This.
There is one user parm with a menu script.
I would like to access kwargs-type data.
There is one user parm with a menu script.
I would like to access kwargs-type data.
Technical Discussion » Can I determine whaat parameter is calling a menu script?
- Shumberg
- 14 posts
- Offline
Is there a way to determine what the calling parm is when a menu script is run?
The usual kwargs data does not appear to be availiable, which can be problematic in a multiparm situation. It seems the best I can do is to run some kind of post/validation job as an additional parm callback (ugh).
If this is currently impossible, then this would be a useful RFE.
The usual kwargs data does not appear to be availiable, which can be problematic in a multiparm situation. It seems the best I can do is to run some kind of post/validation job as an additional parm callback (ugh).
If this is currently impossible, then this would be a useful RFE.
Technical Discussion » Wire object friction does not seem to work?
- Shumberg
- 14 posts
- Offline
I am dropping a wire object onto a slightly inclined ground surface. It collides fine, but begins to slide ‘downhill’ - I want it to just rest on the surface. I have the friction on both the wire and the ground set to 1.
H 11.0.441
H 11.0.441
Technical Discussion » Sprite Attribute Override
- Shumberg
- 14 posts
- Offline
If you are doing an override of something in a multi-component material (for example, a material with surface and displacement shaders, or a surface and geometry shader like your case), the way I have gotten this to work is to promote the parameters up to the material node (right-click on the material ‘Promote Material Parameters’) and then point your material SOP at the material. Then override away…
Also make sure to turn on the ‘Overrides use local variables’ toggle if you want something like $PR to evaluate correctly.
Also make sure to turn on the ‘Overrides use local variables’ toggle if you want something like $PR to evaluate correctly.
Technical Discussion » RFE: Display of bg images to be tied to camera use
- Shumberg
- 14 posts
- Offline
It seems that H9 updates the image source based on a camera change, but it would be nice if the state of ‘Display Background Images’ could be (optionally) driven by whether you are actually looking through that camera.
Assuming you had ‘Display Background Images’ checked and this option also checked, if you are looking through the camera, the bg is displayed. If you are not (you move your view, switch to another camera (which does not have a view roto defined), whatever), the bg is not displayed.
Assuming you had ‘Display Background Images’ checked and this option also checked, if you are looking through the camera, the bg is displayed. If you are not (you move your view, switch to another camera (which does not have a view roto defined), whatever), the bg is not displayed.
Technical Discussion » What is legal in a SOP solver's SOP chain? (Could be an RFE)
- Shumberg
- 14 posts
- Offline
I am trying to use the Pops solver in Dops, basically to get levelset collisions.
It works. But what I am stuck on now is trying to get data that I can see in the details view (say, ‘Impulse’), stuck back on to the appropriate particles.
There don't seem to be operators or expressions to apply dopfield-type data back onto geometry. It seems that for this kind of thing, you would try a multi solver/SOP solver setup.
So I can do something simple, like change my particles' colors with a point SOP. The basic framework seems to work. But when I try to do something useful, I seem to just make Houdini crash. One problem with this is that this transient collision data is sorted only by some point number scheme, so you need to do some kind of id lookup to get it to go to the right place. So the most direct thing to me seemed like writing a python SOP to maybe build some useful data structure for the relevant dopfield() fields and then applying the attributes to the correct particles. But my first simple python sop (which tested fine in a plain old /obj/geo/ application) just crashed houdini in a sop solver.
I also tried Chops, and using the dynamics chop seemed promising, but trying to use a geometry chop in this (sop solver) context also crashes Houdini. The closest I got here was using data that I dug out with the dynamics chop to generate a new particle system, and then attribute transferring the relevant data back onto the original system. This actually kind of worked (well, sort of).
What is needed (i think) is a sop solver-friendly sop (or pop solver-friendly pop?) which can be pointed at a bit of dop data and will place it on a point as some user named attribute. And/or some kind of HOM support for doing this kind of thing in a script solver (I poked around there too - couldn't find a way to alter ‘Geometry’ type data).
Any suggestions? I guess I might try VEX next, but there seems to be an underlying ‘touchiness’ to the Sop solver, so I am not particlularly confident…
This was with various recent cuts of 9.0/9.1 on Linux.
It works. But what I am stuck on now is trying to get data that I can see in the details view (say, ‘Impulse’), stuck back on to the appropriate particles.
There don't seem to be operators or expressions to apply dopfield-type data back onto geometry. It seems that for this kind of thing, you would try a multi solver/SOP solver setup.
So I can do something simple, like change my particles' colors with a point SOP. The basic framework seems to work. But when I try to do something useful, I seem to just make Houdini crash. One problem with this is that this transient collision data is sorted only by some point number scheme, so you need to do some kind of id lookup to get it to go to the right place. So the most direct thing to me seemed like writing a python SOP to maybe build some useful data structure for the relevant dopfield() fields and then applying the attributes to the correct particles. But my first simple python sop (which tested fine in a plain old /obj/geo/ application) just crashed houdini in a sop solver.
I also tried Chops, and using the dynamics chop seemed promising, but trying to use a geometry chop in this (sop solver) context also crashes Houdini. The closest I got here was using data that I dug out with the dynamics chop to generate a new particle system, and then attribute transferring the relevant data back onto the original system. This actually kind of worked (well, sort of).
What is needed (i think) is a sop solver-friendly sop (or pop solver-friendly pop?) which can be pointed at a bit of dop data and will place it on a point as some user named attribute. And/or some kind of HOM support for doing this kind of thing in a script solver (I poked around there too - couldn't find a way to alter ‘Geometry’ type data).
Any suggestions? I guess I might try VEX next, but there seems to be an underlying ‘touchiness’ to the Sop solver, so I am not particlularly confident…
This was with various recent cuts of 9.0/9.1 on Linux.
-
- Quick Links