for anyone following - adding the edit material lop near the end of the chain with relative instead of absolute, and it seems to work.
If I were a python wizard (definitely not) i'd write a script to fix this. Unfortunately I'm mostly a hack.
Alas, there's also a lot of other things that break with remote KarmaXPU / USD rendering that I'm slogging through one piece at a time.
Found 20 posts.
Search results Show results as topic list.
Solaris and Karma » Issue with Karma / Solaris render on remote render farm
- evanmathis
- 20 posts
- Offline
Solaris and Karma » Issue with Karma / Solaris render on remote render farm
- evanmathis
- 20 posts
- Offline
OK I've been wrestling this for a couple of days now -
Trying to render a USD / Karma XPU scene on GridMarkets.
I did the preflight, made sure everything I could see was using relative paths to $HIP.
When I render locally, everything is of course fine.
But when I went to render on the GridMarkets farm, lots of stuff just came up missing.
The jobs still rendered, but I had a few USDs being loaded to scatter, and pretty much everything that was loaded into the layout nodes was missing.
These were all Quixel assets that I converted to USD in Houdini, and when doing so, the texture paths became absolute.
So now I'm trying to figure out a solution to fix these that isn't adding an edit material properties LOP for every texture.
Trying to render a USD / Karma XPU scene on GridMarkets.
I did the preflight, made sure everything I could see was using relative paths to $HIP.
When I render locally, everything is of course fine.
But when I went to render on the GridMarkets farm, lots of stuff just came up missing.
The jobs still rendered, but I had a few USDs being loaded to scatter, and pretty much everything that was loaded into the layout nodes was missing.
These were all Quixel assets that I converted to USD in Houdini, and when doing so, the texture paths became absolute.
So now I'm trying to figure out a solution to fix these that isn't adding an edit material properties LOP for every texture.
Edited by evanmathis - March 15, 2024 16:00:51
Solaris and Karma » Karma / Mtlx animated texture - start frame?
- evanmathis
- 20 posts
- Offline
for those following along, this is the wrong way to do it, but it works:
My frame offset is 509 (I don't want to see this texture animate until frame 509 of 1440)
I used an edit material properties lop, and in the file name I added `$F-509`.png
So it throws a missing texture error in the log until frame 509, but renders fine and doesn't crash.
I'll eventually figure out the right way, but for now this works.
My frame offset is 509 (I don't want to see this texture animate until frame 509 of 1440)
I used an edit material properties lop, and in the file name I added `$F-509`.png
So it throws a missing texture error in the log until frame 509, but renders fine and doesn't crash.
I'll eventually figure out the right way, but for now this works.
Solaris and Karma » Karma / Mtlx animated texture - start frame?
- evanmathis
- 20 posts
- Offline
evanmathis
Would the frame offset parameter on the mtlx image node do this with a negative number?
lol, nope.
Solaris and Karma » Karma / Mtlx animated texture - start frame?
- evanmathis
- 20 posts
- Offline
I've got animated textures in mtlx / karma working fine, but i have one where i want to hold its start frame.
For instance:
My timeline is 1000 frames long.
My animated sequence is 750 frames long
I want the animated sequence to start at frame 250 / or backtime it from the last frame.
Would the frame offset parameter on the mtlx image node do this with a negative number?
Is there another way?
For instance:
My timeline is 1000 frames long.
My animated sequence is 750 frames long
I want the animated sequence to start at frame 250 / or backtime it from the last frame.
Would the frame offset parameter on the mtlx image node do this with a negative number?
Is there another way?
Solaris and Karma » Solaris Large Scene question / best practices?
- evanmathis
- 20 posts
- Offline
goldleaf
If you aren't able to re-export your USD assets using the Component Builder, you could unlock each of the Asset Reference nodes, and on the Reference LOP inside, switch the type over to 'payload file' instead of 'reference file'; then insert a Loft Payload Info that @mtucker mentioned, between the align_to_up_axis and OUT nodes. Set the primitives to `chs("../primpath")`and that should help your scene to be more un-loadable.
Thanks for this I'll give this a go!
I was on a bit of a nutty deadline and did the thing that we all do: come up with a panicky solution that does the job.
In my case, I have several big groups of assets that all funnel through their own single merge node, all merged into one big geo tree. So right after each big merge, i just put a switch between the merge node and an empty null. Then I made a control null with it's own little system of checkboxes to control the switches, because the group editor thing (shift+z) doesn't work on the stage like it does in obj.
Solaris and Karma » Solaris Large Scene question / best practices?
- evanmathis
- 20 posts
- Offline
Not a silly question at all... I'm an absolute noob with USD, so still trying to figure things out and I have no shame in being told "you're doing it wrong".
I'm using the asset reference node to load in my usd assets.
This is probably a me issue, and I'm likely using the wrong method to do this.
My files were not built with payloads (yes, i should have but its too late now), and i absolutely understand that will prevent me from unloading them.
I guess I could reframe my question as "can i add / create the payloads" once the assets have been loaded into the scene?
Which in itself is probably a stupid question, lol, but I'm just not sure.
thanks again for your responses, they are absolutely helpful.
I'm using the asset reference node to load in my usd assets.
This is probably a me issue, and I'm likely using the wrong method to do this.
My files were not built with payloads (yes, i should have but its too late now), and i absolutely understand that will prevent me from unloading them.
I guess I could reframe my question as "can i add / create the payloads" once the assets have been loaded into the scene?
Which in itself is probably a stupid question, lol, but I'm just not sure.
thanks again for your responses, they are absolutely helpful.
Solaris and Karma » Migrating USD paths from Windows to Linux?
- evanmathis
- 20 posts
- Offline
I have different machines using different paths, one windows and one linux.
I've set up a couple of specific variables for where things should go that use the same naming:
For instance $CACHE goes to E:/localcache on Win and /mnt/md0/localcache on Linux (both internal raids, but do the same job).
I have various variables that lead to $HDR, $MODEL_LIBRARY, $TEX etc that point to specific server locations, but formatted for Win and Linux respectively.
I've set up a couple of specific variables for where things should go that use the same naming:
For instance $CACHE goes to E:/localcache on Win and /mnt/md0/localcache on Linux (both internal raids, but do the same job).
I have various variables that lead to $HDR, $MODEL_LIBRARY, $TEX etc that point to specific server locations, but formatted for Win and Linux respectively.
Solaris and Karma » Solaris Large Scene question / best practices?
- evanmathis
- 20 posts
- Offline
Thanks for this!
Glad that the way I'm approaching a bigger scene is seemingly working.
I'll have to dig into the Loft Payload LOP. I'm currently bringing in USD files as references, and I can't seem to sort out any way to unload the payloads in my current workflow...
Glad that the way I'm approaching a bigger scene is seemingly working.
I'll have to dig into the Loft Payload LOP. I'm currently bringing in USD files as references, and I can't seem to sort out any way to unload the payloads in my current workflow...
Solaris and Karma » Solaris Large Scene question / best practices?
- evanmathis
- 20 posts
- Offline
I've been building all of the assets for what will be a pretty heavy scene, asset wise.
So far, so good... time to 1st pixel with XPU is about 2 seconds on a pretty decent machine. This same setup in OBJ made redshift fall over, even with making all of the geo RS proxies.
But I'm about to start adding more hero / complex / simulations / animations and want to be sure I'm going about this right.
1. Load all of the geo. I've got almost everything that isn't a sim built and textured and loaded as a reference. (handy hint here: if you texture in Substance Painter it does a great job of spitting out USD files that are ready to reference)
2. I have some textures that are animated and shared across several of the references, and Solaris doesn't seem to like using time based textures in the references, so I used an edit material properties and replaced the textures with /geo/*/newMaterial.$F.png and that worked pretty well.
3. Any additional texture assignments in the mat lib, and a camera lens shader
4. Lights
5. Cameras
6. Render settings
7. USD Render Rop
So before I get crazy with the really heavy elements:
Should I be using bog standard merge nodes for all of the geometry? Each ref has a proper entry in the tree, and that will continue.
I've got the geo broken out by LOD here. Hero, close, medium and far. (thus the 4 different clusters / merges)
While creating most of the USD references I have now directly out of Substance is fast and convenient, these files are not created with payload info. Is there a way to add that in Solaris after the fact?
The following URLs are suuuuper helpful and deep, and I'm posting here so that anyone looking for similar solutions can dig through these as well:
https://www.sidefx.com/docs/houdini/solaris/performance.html [www.sidefx.com]
https://lucascheller.github.io/VFX-UsdSurvivalGuide/index.html [lucascheller.github.io]
But I'm also asking here to see what the folks that have much more technical knowledge that I (pretty much all of you) might be able to give some quick advice on pitfalls and other things you've come across that might be helpful.
thanks!
So far, so good... time to 1st pixel with XPU is about 2 seconds on a pretty decent machine. This same setup in OBJ made redshift fall over, even with making all of the geo RS proxies.
But I'm about to start adding more hero / complex / simulations / animations and want to be sure I'm going about this right.
1. Load all of the geo. I've got almost everything that isn't a sim built and textured and loaded as a reference. (handy hint here: if you texture in Substance Painter it does a great job of spitting out USD files that are ready to reference)
2. I have some textures that are animated and shared across several of the references, and Solaris doesn't seem to like using time based textures in the references, so I used an edit material properties and replaced the textures with /geo/*/newMaterial.$F.png and that worked pretty well.
3. Any additional texture assignments in the mat lib, and a camera lens shader
4. Lights
5. Cameras
6. Render settings
7. USD Render Rop
So before I get crazy with the really heavy elements:
Should I be using bog standard merge nodes for all of the geometry? Each ref has a proper entry in the tree, and that will continue.
I've got the geo broken out by LOD here. Hero, close, medium and far. (thus the 4 different clusters / merges)
While creating most of the USD references I have now directly out of Substance is fast and convenient, these files are not created with payload info. Is there a way to add that in Solaris after the fact?
The following URLs are suuuuper helpful and deep, and I'm posting here so that anyone looking for similar solutions can dig through these as well:
https://www.sidefx.com/docs/houdini/solaris/performance.html [www.sidefx.com]
https://lucascheller.github.io/VFX-UsdSurvivalGuide/index.html [lucascheller.github.io]
But I'm also asking here to see what the folks that have much more technical knowledge that I (pretty much all of you) might be able to give some quick advice on pitfalls and other things you've come across that might be helpful.
thanks!
Solaris and Karma » Flip Fluids and Solaris: Best Practices?
- evanmathis
- 20 posts
- Offline
sanostol
Hello, are writing usds per frame or one big file for all frames?
anyway, delete all unnecessary attributes before writing to disc.
I was trying to just write the single file (big) file, and was using attribute delete to strip out some unnecessary stuff.
tamte
Reference the bgeo sequence directly as value clips using Geometry Clip Sequence
Ah this is great!
FWIW - I've been successful with modeling / texturing all of my static elements and saving as individual USD then just bringing in as an asset reference. I was hoping to achieve the same thing with the fluid, and it looks like i sort of can do that, i will just need to re-apply the textures.
thanks to both of you!
Solaris and Karma » Flip Fluids and Solaris: Best Practices?
- evanmathis
- 20 posts
- Offline
I'm still trying to get the hang of working in Solaris / USD, and I'm pretty pleased with the results so far.
But my dilemma is this: I cooked up a flip simulation, nothing too complicated, with the plan of building it in it's own HIP file, export it as a USD, then bring it into a pretty large scene in a different HIP file that I've been assembling.
But the USD files for the flips exports were weighing in at like 50gb, I guess they were storing all of the data that was already cooked in the USD file?
Because it was pretty simple, I just merged the flip hip with the large scene hip, and that will work, but was curious if there was a better way to do something like this?
But my dilemma is this: I cooked up a flip simulation, nothing too complicated, with the plan of building it in it's own HIP file, export it as a USD, then bring it into a pretty large scene in a different HIP file that I've been assembling.
But the USD files for the flips exports were weighing in at like 50gb, I guess they were storing all of the data that was already cooked in the USD file?
Because it was pretty simple, I just merged the flip hip with the large scene hip, and that will work, but was curious if there was a better way to do something like this?
Technical Discussion » Randomize attribs for items within a group in copy to points
- evanmathis
- 20 posts
- Offline
I'll probably just cheat this by making 3-4 different arrangements of chairs and table settings and instancing them to a grid in Solaris.
Technical Discussion » Randomize attribs for items within a group in copy to points
- evanmathis
- 20 posts
- Offline
OK this is me trying to sort out some of the *how* in Houdini.
I'm not suuuper technical, but I don't mind digging into code.
What I'm trying to do:
I have a couple of pieces of geo that I'm looking to assemble, then copy that group of things to a grid of points, with each piece of geo having a couple of attributes randomized within a range.
In this case, I have a table, 4 chairs, a ketchup bottle, a mustard bottle, a napkin dispenser, and salt and pepper.
My thinking is that I would need to establish what attributes need to be affected, figure out the range that they should work within, then probably run that through a for loop to affect the attributes as they distribute the groups of geo to the points.
I've got a good handle on how to handle randomizing attributes if i just want to scatter a bunch of different things to a grid, but i'm not quite sure about how for loops would do this, in order to keep things positioned naturally.
essentially i'm trying to fill an area with tables and chairs with props on the table in a somewhat specific, but controllably randomized way.
I'm just not sure how to start tinkering to make that work.
I'm not suuuper technical, but I don't mind digging into code.
What I'm trying to do:
I have a couple of pieces of geo that I'm looking to assemble, then copy that group of things to a grid of points, with each piece of geo having a couple of attributes randomized within a range.
In this case, I have a table, 4 chairs, a ketchup bottle, a mustard bottle, a napkin dispenser, and salt and pepper.
My thinking is that I would need to establish what attributes need to be affected, figure out the range that they should work within, then probably run that through a for loop to affect the attributes as they distribute the groups of geo to the points.
I've got a good handle on how to handle randomizing attributes if i just want to scatter a bunch of different things to a grid, but i'm not quite sure about how for loops would do this, in order to keep things positioned naturally.
essentially i'm trying to fill an area with tables and chairs with props on the table in a somewhat specific, but controllably randomized way.
I'm just not sure how to start tinkering to make that work.
3rd Party » Megascan not working
- evanmathis
- 20 posts
- Offline
not sure if this is just me or not, but the megascans plugin was working just fine in 19.5.773, but now in 20, the "import to USD stage" checkbox is greyed out.
Houdini Lounge » Karma XPU (H20) vs Redshift
- evanmathis
- 20 posts
- Offline
I've been making the transition from Redshift to try and use KarmaXPU more in my workflow as well.
Had a few stumbles here and there. But now that I've been working in USD / mtlX / solaris a bit, it's making more and more sense.
A little more work in the setup, but I'm starting to get results similar to RS. The time to fist pixel is way faster in XPU especially in bigger scenes.
I'm not happy about the Adobefication of Maxon, and having a solid option directly developed by SideFX with more open standards is a great thing for me and my workflow.
Had a few stumbles here and there. But now that I've been working in USD / mtlX / solaris a bit, it's making more and more sense.
A little more work in the setup, but I'm starting to get results similar to RS. The time to fist pixel is way faster in XPU especially in bigger scenes.
I'm not happy about the Adobefication of Maxon, and having a solid option directly developed by SideFX with more open standards is a great thing for me and my workflow.
Solaris and Karma » Are animated textures possible in LOPs/Karma?
- evanmathis
- 20 posts
- Offline
Apologies for the thread necro...
I have a bunch geo brought in as USD assets that share a few of the same textures, but each assets has its own path to the material. To change any single one of those textures on one asset is super easy with an edit material properties node.
What I'm trying to figure out: Is there a simple way to change every instance of a particular texture for all assets?
I was thinking of putting the edit material properties further down the chain and try wildcards for the various textures in the various assets:
/geo/*/materials/KB3d_AtlasD/emissive
I'll try that when I'm back on my workstation, but I figured one of you smart folks may have encountered this before.
For context, I'm using motion textures & that has to be assigned outside of the asset (at least that's how I understand it).
I'm using a bunch of kitbash3d assets in a city setup and replacing the emission channels with video / animation.
I have a bunch geo brought in as USD assets that share a few of the same textures, but each assets has its own path to the material. To change any single one of those textures on one asset is super easy with an edit material properties node.
What I'm trying to figure out: Is there a simple way to change every instance of a particular texture for all assets?
I was thinking of putting the edit material properties further down the chain and try wildcards for the various textures in the various assets:
/geo/*/materials/KB3d_AtlasD/emissive
I'll try that when I'm back on my workstation, but I figured one of you smart folks may have encountered this before.
For context, I'm using motion textures & that has to be assigned outside of the asset (at least that's how I understand it).
I'm using a bunch of kitbash3d assets in a city setup and replacing the emission channels with video / animation.
Edited by evanmathis - Nov. 7, 2023 22:07:08
Houdini Lounge » Linux distro with no problems running H19
- evanmathis
- 20 posts
- Offline
3rd Party » H19.622 + Megascans Bridge v4.5
- evanmathis
- 20 posts
- Offline
Well, Quixel updated their Bridge plugin to officially support h19, hooray!
I still can't get it to run under Linux, with the same errors listed above... booo.
Quixel support originally told me "sorry, the plugin doesn't support your DCC".
Hopefully I'll get an actual helpful response now.
I still can't get it to run under Linux, with the same errors listed above... booo.
Quixel support originally told me "sorry, the plugin doesn't support your DCC".
Hopefully I'll get an actual helpful response now.
3rd Party » H19.622 + Megascans Bridge v4.5
- evanmathis
- 20 posts
- Offline
Howdy, I've finally moved over to Linux full time from Windows, and *almost* everything is working just fine... except trying to start the Megascans plugin. It gives me this:
I've poked around a bit, seen some older solves that involve editing the above mentioned MainWindow.py file, but most of those seem to be a year old or more.
Curious if any of you have seen a more recent fix?
Traceback (most recent call last): File "<stdin>", line 10, in <module> File "/mnt/LINUX_CACHE/support/plugins/houdini/4.5/MSLiveLink/scripts/python/MSPlugin/MainWindow.py", line 138, in initializeWindow mWindow = MSMainWindow.getInstance() File "/mnt/LINUX_CACHE/support/plugins/houdini/4.5/MSLiveLink/scripts/python/MSPlugin/MainWindow.py", line 128, in getInstance MSMainWindow() File "/mnt/LINUX_CACHE/support/plugins/houdini/4.5/MSLiveLink/scripts/python/MSPlugin/MainWindow.py", line 41, in __init__ self.SetupMainWindow() File "/mnt/LINUX_CACHE/support/plugins/houdini/4.5/MSLiveLink/scripts/python/MSPlugin/MainWindow.py", line 79, in SetupMainWindow self.optionsUI = UIOptions(self.uiSettings["UI"]["ImportOptions"], self.uiSettingsChanged) TypeError: 'NoneType' object is not subscriptable
I've poked around a bit, seen some older solves that involve editing the above mentioned MainWindow.py file, but most of those seem to be a year old or more.
Curious if any of you have seen a more recent fix?
-
- Quick Links