Have you tried the suggested solutions from the documentation?
Correspondance between Uproperties and the attributes are done using either the uproperty's name (the name of the uproperty in the source code) or it's display name without space (the name used in the details panel).
The "Center of Mass Offset" property can for example, be modified either by using an attribute called unreal_uproperty_centerofmassoffset (using the display name) or unreal_uproperty_comnudge (using the uproperty name).
I'm experiencing the same issue with Foliage Instances being invalid. I did find a hacky workaround that might be useful for some of you (the downside is that it will ignore any offsets you might have added). Following a suggestion from this thread (https://answers.unrealengine.com/questions/161217/when-deforming-the-terrain-foliage-wont-apply-to-i.html), you can Select All, Move them Up enough so everything is above the landscape, and press the key END on your keyboard. That will snap all instances back to the terrain and validate them in the process (most of them anyway). I already contacted SideFX support but haven't heard back yet. I will update this thread when I get a response.
@valdomat - Interesting approach! And good news, I got a response from support today regarding this topic:
This issue has been fixed in today's 18.5 daily build (18.5.399). FoliageTypes can now be instanced via attribute instancers, and we now also update the foliage type/instancers properties using the unreal_uproperty attributes. I've also added support for Interval type properties, which will let you set properties like “CullDistance” using an Int tuple 2 attribute: (in the case of cullDistance, the attribute would be “unreal_uproperty_CullDistance”)
Hello, I'm looking into this same issue right now. I need to be able to instance existing FoliageType actors, but haven't been able to find the correct workflow for this.
I’ve tried adding the path to a Static Mesh Foliage actor as my unreal_instance attribute in Houdini but that didn’t work. I also tried swapping the reference on the HoudiniOutput_Instancer from a StaticMesh to a FoliageType actor and the instances disappear.
What would be the best way to use one mesh for instancing, but have it for example pick its corresponding FoliageType actor to be instanced instead of itself? I’m thinking down the line we will have multiple FoliageTypes derived from the same mesh with different properties such as materials, cull distance, and other gameplay related features, so it would be quite important that the foliage system integration in the Houdini engine supports this somehow.
I'd recommend taking a look at grains. If your source has animated an @pscale attribute and is constrained to a tight space with some opening it will behave exactly like the elephant toothpaste reference you mentioned, after tweaking a some of the parameters. You will want to increase the particles friction, as well as pumping up the clumping. Can't provide a scene file right now, but let me know if you need further help.
Hello, I believe your whole assumption is very correct. Assuming your topology remains unchanged in terms of point count, if you pipe your resulting deformed sphere to a wrangle and the original one to its second input (or vice-versa, really), the code below calculates the distance from their points positions. All you have to do is wire this value to a ramp, and write it to the @Cd attribute.
bcgreen I'm trying to find a tutorial series I went through a couple of years ago– in one of the videos, the instructor created a random rock on each frame of an animation (as I recall), and each was automatically written out to disk. So he was able to spit out 50 random rocks in one fell swoop.
Hey, I did a write-up on a very similar procedure, I think it might be of help.
That looks amazing, Rich! This sort of ever-zooming setup is really interesting. I'd really appreciate a more in-depth explanation how you're approaching this. Cheers!
BrandonA This syntax for internal variables should be replaced with attributes so that they are more transparent and easily configurable. For example, it should be using `@input_images` so that the the input_images can be transparently configured by the user if they wish. This update is on the todo list!
That would be really helpful and much better integrated, thank you.
BrandonA For the use case that you are describing, this should be possible now using the montage operation. {input_images} is substituted with any incoming result files that are tagged as file/image, so we can make use of this to conduct the labelling operation. I've attached a .hip file that demonstrates. Just make sure to put in a valid path to an image file in the parameters of the Attribute Create node. The {overlay_label} text gets substituted with the evaluated contents of the “Expression” parameter.
Yes, however what I meant is that it should be possible to use a montage operation with the {image} variable instead of {input_images}. In specific cases, some operations like labeling work great with the montage operation, and right now the ability to process the images individually as work items is lacking (instead of processing the result of a partition; multiple images). Besides, I think the {overlay_label} text field should be always visible and accessible by any of the operations.
Yes, I absolutely think this would be a great addition. Procedurally generating slates would be a very important feature for anyone that considers using PDG as the core for a pipeline, like you mentioned.
I haven't used ffmpeg much yet, have only been playing around with imagemagick so far, which is also a third party implementation. And I agree with you, I guess if the community express their interests towards specific features SideFX is able to prioritize or plan implementing them.
Hi everyone, basically the title. I'd like to use a montage operation, however by default the command line only accepts {input_images}, and not “{image}”. A work around is to set the operation mode to convert, but change the command line to montage, so that I have access to the “{image}” variable. But this creates new problems. I'd also like to use a custom expression from the montage operation. However since the operation mode is now set to convert, I don't have access to it anymore. Even hard-enabling it through the parameter interface, it just doesn't accept the “{overlay_label}” if the operation mode is set to convert. So, I hope someone could take a look into that. I understand these presets are there to help us, but right now they seem to be useless (since the default command line values lack the operation (convert, montage, etc) in the first place).
Here's what I'm trying to do, just for context.
I have a ROP mantra in TOPs which is rendering a wedged particle simulation. I then want to process all the the frames independently, embed their wedges attributes and other relevant information into their alpha channels as text with a -label command, while converting them to .PNG to keep the file size small (since this is only for viz). Last step would be to partition them all by frame and finally montage them into a final thing, possible even encoding a video from it.
I managed to do that, and the code used for embedding the information to the frames is this:
{imagemagick} montage -background none -label "Attribute `@attribute`" "{image}" -geometry +0+0 "{output_image}" This will work, but like I said, I have to use it in Convert mode Operation, and I have no access to the overlay_label, which would be very handy for embedding a lot of information at once. This will basically be a temporary step for generating the final montage.
Just for reference, here's the log if you try to run this command line while in montage operation mode:
montage: unable to open image ‘{image}’: No such file or directory @ error/blob.c/OpenBlob/3497.
Any help on this subject would be very appreciated. I'm a beginner in TOPs and IM, so if anyone has a better solution to this situation please let me know. I researched a lot about this but I guess there just not a lot of information out there yet, and the documentation about Houdini's IM implementation is not very detailed. It's been a lot of trial and error!