so where does this brings us?
Do we have a problem or its all good?
Found 245 posts.
Search results Show results as topic list.
Technical Discussion » Mplay and Renderview OCIO / ACES display issue
- martinkindl83
- 260 posts
- Offline
Solaris and Karma » how to assign to groups rather than Xforms in Solaris
- martinkindl83
- 260 posts
- Offline
Solaris and Karma » change displayColor with attWrangle
- martinkindl83
- 260 posts
- Offline
also why are you having second line in the vex? is it just safety thing?
As it looks, like the first line already creates constant interpolation.
As it looks, like the first line already creates constant interpolation.
v[]@primvars:displayColor = array(vector(rand(@elemnum))); usd_setprimvarinterpolation(0, @primpath, "displayColor", "constant");
Solaris and Karma » change displayColor with attWrangle
- martinkindl83
- 260 posts
- Offline
Thank you for the example, it worked as expected
string att_name =chs("att_name"); string primitive = chs("primpattern"); usd_addprimvar(0, primitive, att_name, "color3f[]", "constant"); usd_setprimvar(0, primitive, att_name, vector[](array({0,1,0})));
Solaris and Karma » change displayColor with attWrangle
- martinkindl83
- 260 posts
- Offline
jsmack
By file node do you mean sublayer or reference lop?
Originally i was using Alembic node at sops and sopimporting. You mentioned its not the right way how to bring alembic, so i tried File, which is by looking at the name Sublayer node.
Solaris and Karma » how to assign to groups rather than Xforms in Solaris
- martinkindl83
- 260 posts
- Offline
rafal
Scene Graph Details in LOPs roughly corresponds to the geometry spreadsheet in SOPs, so I think you are on the right track.
One suggestion for selecting prims in the Scene Graph Tree: at the bottom of the tree there are two collapsed UI gadgets: filter and selection rules. You can use these to search for your instances to make the selection easier.
Thank you, thats super handy.
Solaris and Karma » change displayColor with attWrangle
- martinkindl83
- 260 posts
- Offline
Solaris and Karma » change displayColor with attWrangle
- martinkindl83
- 260 posts
- Offline
Hello guys.
I'm trying to port some custom HDAs into Solaris and i struggle even with simple VEX expression to change displayColor
Anyone would be able to help how to change the displayColor with VEX?
I managed to get to this stage, but that creates different type (color3f), then then USD displayColor expects (color3f).
I just was not able to get the correct type, thus the Array
I'm trying to port some custom HDAs into Solaris and i struggle even with simple VEX expression to change displayColor
Anyone would be able to help how to change the displayColor with VEX?
I managed to get to this stage, but that creates different type (color3f), then then USD displayColor expects (color3f).
I just was not able to get the correct type, thus the Array
string att_name =chs("att_name"); string primitive = chs("primpattern"); usd_addprimvar(0, primitive, att_name, "color3f[]", "constant"); usd_setprimvar(0, primitive, att_name, vector[] (array({0,0,0},{0,0,0} , {1,1,1})));
Edited by martinkindl83 - Nov. 17, 2020 01:29:16
Solaris and Karma » how to assign to groups rather than Xforms in Solaris
- martinkindl83
- 260 posts
- Offline
rafalOne question from complete different field.
Another potential workflow is to use an attribute on a primitive to determine the material. See attached example.
What would be the best equivalent to geometry spreadsheet in LOPs?
If i would want to inspect material on your instances, i would check geometry spreadsheet and i would see all the values on all prims.
I havent found a simple solution to do the same check in Lops.
I only found: select all the instances in the Composed Scene Graph (not very handy to be forced to select them) and then Scene Graph Details and change it to List View.
M
Solaris and Karma » how to assign to groups rather than Xforms in Solaris
- martinkindl83
- 260 posts
- Offline
rafalahh, i completely forgot about this. I was investigating attributes before i went with groups when at SOP level.
Another potential workflow is to use an attribute on a primitive to determine the material. See attached example.
Good point.
Solaris and Karma » Collection based material assignments
- martinkindl83
- 260 posts
- Offline
when i was asking about collections in another thread, i did test if first with this assignment, that worked fine:
is that valid approach?
is that valid approach?
Edited by martinkindl83 - Nov. 11, 2020 23:37:30
Solaris and Karma » how to assign to groups rather than Xforms in Solaris
- martinkindl83
- 260 posts
- Offline
also how does it affect speed?
if i will have 5000 assets, each having 50 “overrides” to fix bad material assignments in the scene, compared to 5000assets with just one correctly done material assignment?
if i will have 5000 assets, each having 50 “overrides” to fix bad material assignments in the scene, compared to 5000assets with just one correctly done material assignment?
Solaris and Karma » how to assign to groups rather than Xforms in Solaris
- martinkindl83
- 260 posts
- Offline
I do fully understand what and why you are doing it. It has its own logic.
Just have to get my head around if thats something i would be comfortable with or not.
Just have to get my head around if thats something i would be comfortable with or not.
Solaris and Karma » how to assign to groups rather than Xforms in Solaris
- martinkindl83
- 260 posts
- Offline
sorry, but thats even worse in my opinion
as then you will not just to have dig through all the material tabs on one node, but even through multiple material nodes.
I know its possible, but to me it creates even bigger mess to work with. As you will not be fixing the problem, where it occurs (material node it self), but rather create bunch of overrides to hide the problem. Thats my opinion, in no means im not saying your suggested workflow is bad and mine is good, to be clear.
as then you will not just to have dig through all the material tabs on one node, but even through multiple material nodes.
I know its possible, but to me it creates even bigger mess to work with. As you will not be fixing the problem, where it occurs (material node it self), but rather create bunch of overrides to hide the problem. Thats my opinion, in no means im not saying your suggested workflow is bad and mine is good, to be clear.
Solaris and Karma » how to assign to groups rather than Xforms in Solaris
- martinkindl83
- 260 posts
- Offline
Best how to describe the workflow im after is ShadingGroups in Maya (Im not maya person, but its easier to explain). ShadingGroup represents material, and one object cant live in multiple ShadingGroups.
So i create my shadingGroups (red, green, metal) and then i start drag and dropping objects onto those groups in Outliner.
Based on in which shadingGroup the objects is, it will get material. If i decide that objectA should not be red, but metal, i simply drag and drop it from Outliner to shadingGroup metal and it will have metal material, even though it was red before.
So i create my shadingGroups (red, green, metal) and then i start drag and dropping objects onto those groups in Outliner.
Based on in which shadingGroup the objects is, it will get material. If i decide that objectA should not be red, but metal, i simply drag and drop it from Outliner to shadingGroup metal and it will have metal material, even though it was red before.
Solaris and Karma » how to assign to groups rather than Xforms in Solaris
- martinkindl83
- 260 posts
- Offline
Groups and collections can have overlaps, that's why i have build my custom node that creates groups and takes care of duplicity (and i want to build same tool in LOPs operating on collections (or what ever i decide to be suitable)).
with materials where the last one wins, look at my example.
In first step i assigned Bucket being blue and Rope being green and Screw being red.
In next step i realized that my assignment is wrong and that Bucket needs to be Red as well, so i do drag and drop my Bucked onto red, but it will still render blue. I have to also go and manually remove it from blue assignment. On lot of materials, this is impossible to do.
with materials where the last one wins, look at my example.
In first step i assigned Bucket being blue and Rope being green and Screw being red.
In next step i realized that my assignment is wrong and that Bucket needs to be Red as well, so i do drag and drop my Bucked onto red, but it will still render blue. I have to also go and manually remove it from blue assignment. On lot of materials, this is impossible to do.
Edited by martinkindl83 - Nov. 11, 2020 21:20:50
Solaris and Karma » how to assign to groups rather than Xforms in Solaris
- martinkindl83
- 260 posts
- Offline
thank you
as later assignments overwrite previous ones
that's exactly what i have the biggest issue with. As you will have one object living in several materials without actually knowing it. So you will reassign object to materialA, you will wonder why its not working and then you realize that some other material down the line is actually overwriting it. and then you might realize that there is actually another material that overwrites it again. with 150 materials, its impossible to fix those without lot of effort.
Which makes it nightmare to work with, thus why i want to create unique groups/collections/what ever that does take care of this duplicity. If it makes sense
as later assignments overwrite previous ones
that's exactly what i have the biggest issue with. As you will have one object living in several materials without actually knowing it. So you will reassign object to materialA, you will wonder why its not working and then you realize that some other material down the line is actually overwriting it. and then you might realize that there is actually another material that overwrites it again. with 150 materials, its impossible to fix those without lot of effort.
Which makes it nightmare to work with, thus why i want to create unique groups/collections/what ever that does take care of this duplicity. If it makes sense
Solaris and Karma » how to assign to groups rather than Xforms in Solaris
- martinkindl83
- 260 posts
- Offline
jsmack
Geometry isn't always authored in a way to makes the assignments by hierarchy convenient.
Thank you.
Im doing some reading of USD at tokeru, that might give me some more answers.
But in a mean time. How would you shade and assign materials in the following scenario?
You have 150 materials, you have asset with 20.000 pieces. There is no usable hierarchy for shading and no usable names on the pieces.
I have created whole workflow in SOPs to make this possible to work with, now im trying to do similar in LOPs.
My problem is that if you will have one materialAssign node, where you assign all pieces by selecting them in viewport, next time you asked to change pieceA from materialA to materialB, you have to go and find the materialA tab (with 150tabs, its very hard), remove it from materialA, then find materialB tab and add it to materialB.
What i have instead in SOP is “group”node that allows only unique assignments, so one object can live only in one group. once i assign that piece to another group it gets automatically removed from previous group. User creates 150groups, that later on correspond to creating 150 materials, that are assigned based on the group name. Basically replicating shadingGroups from maya or XSI groups logic.
Option with USD might be to “recreate” hierarchy based on materials and then be assigning materials based on that hierarchy. That sound reasonable, but im little bit of worried about “killing” the original hierarchy. As in some cases it might be actually good and can be used for other things down the road.
Solaris and Karma » how to assign to groups rather than Xforms in Solaris
- martinkindl83
- 260 posts
- Offline
Thank you for quick reply.
I do load my alembic at sop level, create my unique groups for shading and then sopimport them to LOPs.
I can build my uniqueGroup tool in LOPs in the future, but i need to be certain what approach i will be using. If collections are the best thing to use. Ideally i want to have unique “containers” that would contain unique geometry, and later on, i can use those “containers” to assign materials.
In SOPs, easiest was to work with Groups, make sure they contain unique assignments (one object cant live in two groups) and then assign shaders based on groups. As the logic here is the same - you cant assign two materials to one object.
Another option would be to create “my own hierarchy” just for the shading purposes, but that doesnt sounds right, as i already might have some nice hierarchy coming from alembic. Just not the hierarchy i would like for shading though.
I do load my alembic at sop level, create my unique groups for shading and then sopimport them to LOPs.
I can build my uniqueGroup tool in LOPs in the future, but i need to be certain what approach i will be using. If collections are the best thing to use. Ideally i want to have unique “containers” that would contain unique geometry, and later on, i can use those “containers” to assign materials.
In SOPs, easiest was to work with Groups, make sure they contain unique assignments (one object cant live in two groups) and then assign shaders based on groups. As the logic here is the same - you cant assign two materials to one object.
Another option would be to create “my own hierarchy” just for the shading purposes, but that doesnt sounds right, as i already might have some nice hierarchy coming from alembic. Just not the hierarchy i would like for shading though.
Solaris and Karma » how to assign to groups rather than Xforms in Solaris
- martinkindl83
- 260 posts
- Offline
Thank you for fast reply. I don't understand why I would need to strip down the @path attribute? As that's what builds the hierarchy.
What about converting my groups to simple string attribute and then create collections based on that attribute?
Idea is to have collections (if collection is the clisest I can get to groups in Lops) before my material assign node.
What about converting my groups to simple string attribute and then create collections based on that attribute?
Idea is to have collections (if collection is the clisest I can get to groups in Lops) before my material assign node.
-
- Quick Links