Is there a way to tell sop import to index any string attributes dynamically? They're indexed in Houdini, but they're deindexed when it comes into LOPs unless I specifically set those attributes to be indexed. In general, I just want any string attribute to be indexed. I could write a little python script to report all the string attributes here, but I'm looking for something built in, since this seems like it would be what should be a pretty standard behavior.
Thanks,
Ben
Found 13 posts.
Search results Show results as topic list.
Solaris and Karma » SOP Importing indexed string attributes
- ben.andersen
- 46 posts
- Offline
Houdini Indie and Apprentice » BakeTexure Rendering white
- ben.andersen
- 46 posts
- Offline
I've got the same issue, except I don't want to bake in the lighting. I want to render the point color to a texture file or a constant shaded texture to a file.
I have UVs and it renders white with point or vertex colors and with or without a constant shader.
Is there a way to bake a texture without lighting?
I have UVs and it renders white with point or vertex colors and with or without a constant shader.
Is there a way to bake a texture without lighting?
Edited by ben.andersen - 2020年10月5日 01:13:15
Solaris and Karma » Remove a USD attribute from the layer it is defined?
- ben.andersen
- 46 posts
- Offline
Okay, thanks I'll look into the Sdf API :-)
I guess the same concern should apply to the stage manager too, right? Since deleting a prim from a layer won't actually delete it if the prim is defined elsewhere?
I guess the same concern should apply to the stage manager too, right? Since deleting a prim from a layer won't actually delete it if the prim is defined elsewhere?
Solaris and Karma » Remove a USD attribute from the layer it is defined?
- ben.andersen
- 46 posts
- Offline
I want to do the equivalent of a stage manager operation on an attribute.
It's not really a valid USD operation, as far as I understand it. However, if I know that the primitive is defined in the same layer, I'm hoping that there is a way simply to remove it. Or omit it from being written to the USD file at write time would also be fine.
Is there a way to do this?
Thanks!
It's not really a valid USD operation, as far as I understand it. However, if I know that the primitive is defined in the same layer, I'm hoping that there is a way simply to remove it. Or omit it from being written to the USD file at write time would also be fine.
Is there a way to do this?
Thanks!
Technical Discussion » How to snap playbar to the frame increment?
- ben.andersen
- 46 posts
- Offline
Yeah, the arrow keys work, but they still only move by the increment amount instead of snapping to the appropriate increment.
For example, if I click on the timeline and end up at frame 1027.32, if my step is .5, the frame I would probably care about is 1027 or 1027.5. If I press back, I will end up at 1026.82 instead of 1027.0.
I've submitted an RFE for it :-)
For example, if I click on the timeline and end up at frame 1027.32, if my step is .5, the frame I would probably care about is 1027 or 1027.5. If I press back, I will end up at 1026.82 instead of 1027.0.
I've submitted an RFE for it :-)
Technical Discussion » How to snap playbar to the frame increment?
- ben.andersen
- 46 posts
- Offline
When I set the playbar increment to .5, is there a way for me to get the playbar to snap to .5 increments when I click on some random frame on the playbar?
Thanks,
Ben
Thanks,
Ben
Technical Discussion » Reversing baked retime values
- ben.andersen
- 46 posts
- Offline
Okay, I have it figured out. Short answer is that I can't easily solve it in CHOPs (or at least I can't with my limited skill with CHOPs).
My solution was basically to use CHOPs to get the initial curve, then make a python callback to grab the hou.Tracks off the chop node.I then build an animation curve from the two values, swapping the X and Y axes, and then using `chf` to look up the appropriate value.
My problem earlier is that it doesn't seem easy to swap the X and Y axes in CHOPs itself. The shuffle node creates a bunch of different tracks, which isn't really suitable for me.
My solution was basically to use CHOPs to get the initial curve, then make a python callback to grab the hou.Tracks off the chop node.I then build an animation curve from the two values, swapping the X and Y axes, and then using `chf` to look up the appropriate value.
My problem earlier is that it doesn't seem easy to swap the X and Y axes in CHOPs itself. The shuffle node creates a bunch of different tracks, which isn't really suitable for me.
Technical Discussion » Reversing baked retime values
- ben.andersen
- 46 posts
- Offline
I have some shot animation that was matched to a non linearly retimed plate. I want to make it linear again.
I have the curve that would otherwise transform a linear shot to the retimed shot, and I'm just struggling to figure out how to apply the curve in reverse. I have the curve in CHOPs with a chan file, but I'd give my CHOPs score a C- on a good day.
The retime curve remaps 919-1163 to 1001-1050, with a change in retime rate happening at around frame 1008.
I put together a sanity check timeshift for myself to see what the final output values *should* look like, and it looks like I should be arriving at values of 1009.3-1013.4, with the change in rate occurring at 1010.9. So… 4.1 is the range of values I'm looking for in the end.
It occurred to me that maybe I needed to base it off the slope of the curve and not the absolute values. If the retime was jumping by 5 frames for each real frame, then it makes sense that the inverse would jump by .2. Summing up the inverse values would then give me some kind of inverted curve. Unfortunately, I think I'm still a bit off the mark. Summing up all the inverse values gives me a value range of 17.7, which is obviously higher than the 4.1 target value. And that's to say nothing about getting the right offset value.
Has anyone solved this before? Or maybe someone can suggest something else I should look into?
Thanks,
Ben
I have the curve that would otherwise transform a linear shot to the retimed shot, and I'm just struggling to figure out how to apply the curve in reverse. I have the curve in CHOPs with a chan file, but I'd give my CHOPs score a C- on a good day.
The retime curve remaps 919-1163 to 1001-1050, with a change in retime rate happening at around frame 1008.
I put together a sanity check timeshift for myself to see what the final output values *should* look like, and it looks like I should be arriving at values of 1009.3-1013.4, with the change in rate occurring at 1010.9. So… 4.1 is the range of values I'm looking for in the end.
It occurred to me that maybe I needed to base it off the slope of the curve and not the absolute values. If the retime was jumping by 5 frames for each real frame, then it makes sense that the inverse would jump by .2. Summing up the inverse values would then give me some kind of inverted curve. Unfortunately, I think I'm still a bit off the mark. Summing up all the inverse values gives me a value range of 17.7, which is obviously higher than the 4.1 target value. And that's to say nothing about getting the right offset value.
Has anyone solved this before? Or maybe someone can suggest something else I should look into?
Thanks,
Ben
Technical Discussion » Houdini 17.5 Dragging Nodes On Multiple Wires Changed
- ben.andersen
- 46 posts
- Offline
I see this too. I'm curious about how to revert the behavior to how dragging nodes on to wire worked in 17.0 and earlier.
Technical Discussion » Generating HDAs from Python - adding a Python Module
- ben.andersen
- 46 posts
- Offline
check out addSection() on
https://www.sidefx.com/docs/houdini/hom/hou/HDADefinition.html [www.sidefx.com]
and then
https://www.sidefx.com/docs/houdini/hom/hou/HDASection.html [www.sidefx.com]
You want to do something like
https://www.sidefx.com/docs/houdini/hom/hou/HDADefinition.html [www.sidefx.com]
and then
https://www.sidefx.com/docs/houdini/hom/hou/HDASection.html [www.sidefx.com]
You want to do something like
pm_section = node.type().definition().addSection("PythonModule") pm_section.setContents(your_python_module_contents)
Technical Discussion » Scene Scale
- ben.andersen
- 46 posts
- Offline
This has been asked a few times before, I wanted to see how other people and studios are dealing with the differences between applications' preferred scene unit scale.
The rest of our pipeline is currently modeling, animating, and rendering in decimeters.
Houdini defaults to meters, and I've been a little bit afraid to change that.
In the past I've experienced problems where some values did not get adjusted properly and some values don't have physical correlations (looking at you, flame height on the pyro solver), and I don't know what I'd need to do balance that at a different world scale.
The thing that worries me most is that when I put down a shelf example at the default of meters, it will look different than the same example will when I change the scene scale from meters to decimeters.
So my solution has been to scale assets as they come into Houdini into meters, then scale them back again on the way out. This happens automatically without any artist intervention and it works reasonably well.
One problem that we've encountered with that is that volume density is off by a factor of 10. I'm a little surprised by this, since I'd have hoped that renderers have a unit scale as well, for aggregating density along a ray. So we have the option of adjusting the shader when we export it, or adjusting the voxel values directly. I don't really want to do either, but I think that maybe adjusting the voxel scalar values on the way out is preferable to having to change the shader.
Other headaches around having a scene scale different than the rest of the pipe is that lights and cameras don't like to be scaled in Houdini, so we need to scale the translates. And light intensities and falloffs all need to be adjusted as well.
Anyway. Does anyone have a silver bullet for me? Maybe I should just get used to the settings and differences in Houdini working in decimeters? If someone has experience working this way, have you had any issues?
Thanks,
Ben
The rest of our pipeline is currently modeling, animating, and rendering in decimeters.
Houdini defaults to meters, and I've been a little bit afraid to change that.
In the past I've experienced problems where some values did not get adjusted properly and some values don't have physical correlations (looking at you, flame height on the pyro solver), and I don't know what I'd need to do balance that at a different world scale.
The thing that worries me most is that when I put down a shelf example at the default of meters, it will look different than the same example will when I change the scene scale from meters to decimeters.
So my solution has been to scale assets as they come into Houdini into meters, then scale them back again on the way out. This happens automatically without any artist intervention and it works reasonably well.
One problem that we've encountered with that is that volume density is off by a factor of 10. I'm a little surprised by this, since I'd have hoped that renderers have a unit scale as well, for aggregating density along a ray. So we have the option of adjusting the shader when we export it, or adjusting the voxel values directly. I don't really want to do either, but I think that maybe adjusting the voxel scalar values on the way out is preferable to having to change the shader.
Other headaches around having a scene scale different than the rest of the pipe is that lights and cameras don't like to be scaled in Houdini, so we need to scale the translates. And light intensities and falloffs all need to be adjusted as well.
Anyway. Does anyone have a silver bullet for me? Maybe I should just get used to the settings and differences in Houdini working in decimeters? If someone has experience working this way, have you had any issues?
Thanks,
Ben
Technical Discussion » Permission error in blackboxed HDA
- ben.andersen
- 46 posts
- Offline
Yeah, normally you can put two nodes into the same HDA file, but not if one is blackboxed and the other isn't.
One other (even worse) solution would be for the node to generate an external subnet when you put it down, with an object merge to pull it back inside the node in the blackboxed hda.
In my experience, blackboxing of HDAs doesn't seem totally finished. Still has a bit more to go. Maybe file an RFE to get them some attention :-)
One other (even worse) solution would be for the node to generate an external subnet when you put it down, with an object merge to pull it back inside the node in the blackboxed hda.
In my experience, blackboxing of HDAs doesn't seem totally finished. Still has a bit more to go. Maybe file an RFE to get them some attention :-)
Technical Discussion » Permission error in blackboxed HDA
- ben.andersen
- 46 posts
- Offline
Hi Michal :-)
Yeah, you can't do that. Allowing an expression to look inside would essentially unblackbox it.
If you need to blackbox it, I'd suggest blackboxing the guts with a second HDA, then having the output of that exposed to the main HDA. That way the bulk of it is protected, but you can see access specific parts of it with a script.
Ben Andersen
Yeah, you can't do that. Allowing an expression to look inside would essentially unblackbox it.
If you need to blackbox it, I'd suggest blackboxing the guts with a second HDA, then having the output of that exposed to the main HDA. That way the bulk of it is protected, but you can see access specific parts of it with a script.
Ben Andersen
-
- Quick Links