Found 29 posts.
Search results Show results as topic list.
Solaris and Karma » possible to control mipmap level in materialX?
- leoYfver
- 29 posts
- Offline
Solaris and Karma » possible to control mipmap level in materialX?
- leoYfver
- 29 posts
- Offline
I want to be able to control the mipmap level for textures in the shader with a parameter but not sure thats possible. But wanted to check if there is something i missed. Im refering to materialX in karma.
Like in the image belowe I would like for example on this distance to read in the the 256k instead or I would want it to be higher because its a hero asset so it would read 2k at this distance.
Like in the image belowe I would like for example on this distance to read in the the 256k instead or I would want it to be higher because its a hero asset so it would read 2k at this distance.
Edited by leoYfver - Nov. 23, 2023 16:00:01
Solaris and Karma » lossless compression on rendervar with dwaa
- leoYfver
- 29 posts
- Offline
The rules are based on openEXR recommendation. So when the channel names are uppercase it gets compressed and lowercase they dont.
So after this bugfix(attached image) when you export a color rendervar it will be layer.RGBA (compressed) and if you export rendervar as point or vector it will be layer.xyz (not compressed).
Regards Alexis
So after this bugfix(attached image) when you export a color rendervar it will be layer.RGBA (compressed) and if you export rendervar as point or vector it will be layer.xyz (not compressed).
Regards Alexis
Edited by leoYfver - May 1, 2023 06:50:24
Solaris and Karma » pointinstance primvar weaker then prototype
- leoYfver
- 29 posts
- Offline
Solaris and Karma » pointinstance primvar weaker then prototype
- leoYfver
- 29 posts
- Offline
We have an issue where the prototype primvars wins over the ones that are on the pointinstancer. It feel a bit unintuitive to us and i just wonder if it is intended, probably there is a good reason for it but wanted to check.
We solve it now by blocking the primvars on the prototype so there is quite an easy way around it but it does create quite alot of confusion for artists.
Questions:
- should the pointinstancer primvar be stronger then prototypes primvar?
- maybe have a setting on the instancer that does the blocking automagically?
We solve it now by blocking the primvars on the prototype so there is quite an easy way around it but it does create quite alot of confusion for artists.
Questions:
- should the pointinstancer primvar be stronger then prototypes primvar?
- maybe have a setting on the instancer that does the blocking automagically?
Edited by leoYfver - March 22, 2023 09:59:59
Solaris and Karma » Camera switching in stage not working
- leoYfver
- 29 posts
- Offline
thanks rob! really aprreciate this and for the fast and clear respons!
Will take a while until we try a new update in production but will try to test at home atleast.
Regards Alexis
Will take a while until we try a new update in production but will try to test at home atleast.
Regards Alexis
Solaris and Karma » Camera switching in stage not working
- leoYfver
- 29 posts
- Offline
Ok, so it seems like I my value clip didnt get created correctly. I have fixed it in this scene, could you take a look if you can reproduce now?
Edited by leoYfver - March 13, 2023 05:42:43
Solaris and Karma » Camera switching in stage not working
- leoYfver
- 29 posts
- Offline
Thank you both for this thread, its been very informative and being able to switch cameras and bake the animation to the usd is something we have been looking into also.
Though I hit a bit of a snag. It seem like my usd file is fine but when rendering through husk i dont get animated cameras.
1. Our cameras have value clips as animation
2. I switch the cameras and force them to be timesampled to get baked into the usd.
3. I export the usd and all look correct in both solaris and usdview
4. I render through husk and i dont get an animated camera
Is this just a limitation or could it be an issue with husk?
Regards Alexis
Though I hit a bit of a snag. It seem like my usd file is fine but when rendering through husk i dont get animated cameras.
1. Our cameras have value clips as animation
2. I switch the cameras and force them to be timesampled to get baked into the usd.
3. I export the usd and all look correct in both solaris and usdview
4. I render through husk and i dont get an animated camera
Is this just a limitation or could it be an issue with husk?
Regards Alexis
Solaris and Karma » Husk Procedural hair example
- leoYfver
- 29 posts
- Offline
Thanks for the info! We were playing around with attaching non simulated hair like peachfuzz to a deformed body. So we dont have any velocity to transfer and thats why i wondered if it maybe existed something like multisampling. But this is good info and we can workaround it for now and hope for it maybe in the future
Solaris and Karma » Husk Procedural hair example
- leoYfver
- 29 posts
- Offline
elovikov thank you for the example!
Does somebody know if its possible to have this working with motionblur especially with geo samples. Maybe it is possible somehow to sample the geo before and after the frame to create a per frame "cache" to get motionblur on the points with the procedural?
In the image attached you can see that motionblur doesnt work in this case. the rubbertoy has timesamples on the points.
Regards Alexis
Does somebody know if its possible to have this working with motionblur especially with geo samples. Maybe it is possible somehow to sample the geo before and after the frame to create a per frame "cache" to get motionblur on the points with the procedural?
In the image attached you can see that motionblur doesnt work in this case. the rubbertoy has timesamples on the points.
Regards Alexis
Solaris and Karma » Karma and Curves/Hair/Fur
- leoYfver
- 29 posts
- Offline
The wrangle method is the best i think. you can do it as the image attached.
Edited by leoYfver - Feb. 1, 2023 04:07:20
Solaris and Karma » lossless compression on rendervar with dwaa
- leoYfver
- 29 posts
- Offline
Hello!
Im trying build 19.0.632 but cant figure out how to use the per aov compression. Has someone figured it out? There is no setting on the rendervar node and I tried to add it manually with a wrangle like in the image example below but no success.
Im trying build 19.0.632 but cant figure out how to use the per aov compression. Has someone figured it out? There is no setting on the rendervar node and I tried to add it manually with a wrangle like in the image example below but no success.
Solaris and Karma » force render proxy purpose geo
- leoYfver
- 29 posts
- Offline
Unfortunately i cant when they are reference instances like in the hip file i included i only have access to the top/component prim which i can attach variants as suggested by antc
Solaris and Karma » force render proxy purpose geo
- leoYfver
- 29 posts
- Offline
Yes sound like probably the way to go. I wonder if its possible with the component builder to make a variant out of the purposes. The problem now is that we need to do both. One variant setup with the *component geometry variants* node and iniside as purpose. Would be cool if we can get a proxy variant out of the purpose output. Cant really wrap my head how to do that though
Solaris and Karma » force render proxy purpose geo
- leoYfver
- 29 posts
- Offline
Im trying to figure out if its possible to switch a component to force render the proxy purpose instead of render while rendering with karma.
The goal is to be able to switch parts of the environment for example to render as purpose proxy when they are in phantom. Escpecially when they are reference instance as in the example below.
Does somebody now if this is possible, or would solve it in another way with creating variants from the proxy puropse or inherits perhaps?
The goal is to be able to switch parts of the environment for example to render as purpose proxy when they are in phantom. Escpecially when they are reference instance as in the example below.
Does somebody now if this is possible, or would solve it in another way with creating variants from the proxy puropse or inherits perhaps?
Solaris and Karma » lossless compression on rendervar with dwaa
- leoYfver
- 29 posts
- Offline
jsmackleoYfver
update:
seems like its a feature that is missing and a RFE exists now
Are you rendering to the same product? Use a different product to control different image format features.
I had the same thought but when i use usd_render_rop it only picks up the latest renderproduct in the rendersettings list. I just assumed this doesnt work but now when you mentioned it I do get the output from all the renderproducts in the viewport, just not when rendering through husk. I could be doing something wrong too.
Solaris and Karma » lossless compression on rendervar with dwaa
- leoYfver
- 29 posts
- Offline
Solaris and Karma » lossless compression on rendervar with dwaa
- leoYfver
- 29 posts
- Offline
We are using dwaa as compression method on the renderproduct but it breaks the cryptomatte in karma. Is it possible to make some rendervars to be lossless?
Edited by leoYfver - March 18, 2022 09:28:47
Solaris and Karma » usd performance strategy
- leoYfver
- 29 posts
- Offline
jsmack
You're adding nodes to the material library though. of course it has to retranslate to the stage. There's nothing you can do here except don't put a bunch of materials into a library and then edit them there. I would also not use material builders if you don't have to. principled shaders can be translated directly to usd prims, whereas material builders must create code. The code can be cached, but translation would need to happen after any change.
yes, thats what i wrote. The problem is that it happens when creating or deleting a node wherever in the materiallibrary, for example a null node inside a material builder which is not connected will also take seconds to translate. Im not whining just pointing this out a slow part of our workflow.
It doesnt matter if its a materialbuilder it is the nodes that needs to be translated. We use vray and we also use collect nodes with both vray shaders and usdpreview surface connected and it adds up to quite alot shaders quite fast which makes it slow for us.
edit1:
seems actually mtlx subnet is quite faster. But its also because its leaner and seem to only promote the parameters when they are changed from default. unfortunately mtlx is a no go for us for now
edit2:
allright, seems like there is actually 2 different things happening. 1 is vex shaders that needs to translate as jsmack said and the other one which we seem to have issue with is when its alot of non default parameters so it needs to list them all in the graph. Some renderers seem to only list shaders which have non default values. So if for example you have a mtlxsubnet with disney15 surface shader and duplicate that 30 times it will be very snappy, but if you change all the values to non default the slowdown starts to happen.
Edited by leoYfver - March 4, 2022 03:16:23
Solaris and Karma » usd performance strategy
- leoYfver
- 29 posts
- Offline
I did some more testing and in my case it seems to be more about how many shaders need to be translated into the usd stage. In the example attached i only have a materialibrary with a bunch of principled shaders inside a materialbuilder, no other nodes. So if i have the shaders but dont read them into the usd stage the snappiness is back.
Edited by leoYfver - March 3, 2022 05:03:53
-
- Quick Links