i have an obj with groups for materials… how should i assign material for each group after pack primitives…help ?

In the “material” sop you can choose which group to assign material to.

after i convert my geo to packed geometry all groups disapear…

this is what im talking about

I thought that this is normal behavior of packed prims, you lose groups after packing geo.

zhyravetsky
i have an obj with groups for materials… how should i assign material for each group after pack primitives…help ?

This is a complicated question.

If you have geometry as a packed primitive, you can assign a material to the packed primitive (and all the geometry packed away will have that shader applied).

If you want to assign multiple materials to the geometry inside the packed primitive, this gets tricky.

If you assign the shop_materialpath attribute before you pack the geometry, then mantra will use that material if the material has been passed down in the IFD. To ensure the material is passed down in the IFD, you can turn on the “Declare All SHOPs” rendering parameter in the output driver (you'll likely have to add it to the ROP).

If you have multiple copies of the packed primitive and want to assign different materials to the contents of the packed primitive, then right now, you're kind of out of luck. An example of this would be if you have a single character, and you want to make a crowd by copying the packed primitive – but you want to change the color of the character's shirt.

The reason for this is the packed geometry is “locked down” and can't be changed – even at render time. That means that you can't change the attributes on the packed geometry (including materials).

It boils down to the fact that mantra can see the material assignment on the packed primitive and on the geometry that's packed away. You can change the material on the packed primitive, but you can't change the materials inside the packed geometry.

As I mentioned before, you're kind of out of luck (for now). There is a bit of a work-around, which can let you create material variation on copies of a packed primitive. The work-around requires you to modify the shader on the packed primitive a little. When mantra renders a packed primitive, it will take all the attributes on the primitive and create “settings” based on the attribute name. For example, if you create an attribute “shirtcolor” on the packed primitive, in the shader, you can access it using the renderstate VOP:


vector shirtcolor;
if (!renderstate(“packed:shirtcolor”, shirtcolor))
{
// Not a packed primitive
shirtcolor = {1,1,1};
}


This lets you create variations, but it does require materials to be the same on all packed primitives.

Hope this makes sense

mark
This is a complicated question.

If you have geometry as a packed primitive, you can assign a material to the packed primitive (and all the geometry packed away will have that shader applied).

If you want to assign multiple materials to the geometry inside the packed primitive, this gets tricky.

Well, don´t get me wrong, Mark. I appreciate both your explanation and the packed geometry feature, but…seriously, no matter how I look at it, it looks as bad planning.
I mean…how long, after you guys told us how cool packed geo is and how well it works for dynamics, you were expecting for us to try to actually render those dynamics?
The very first thing anybody is going to try is to shatter something, pack it, and sim it.
And then bamf! it doesn´t render properly, because you lost your inside and outside group…not very logical, is it?
Or maybe, we are supposed to unpack every time before render. Which I can live with, but I would expect someone to confirm it if that´s what I gotta do.

Netvudu
Well, don´t get me wrong, Mark. I appreciate both your explanation and the packed geometry feature, but…seriously, no matter how I look at it, it looks as bad planning.
I mean…how long, after you guys told us how cool packed geo is and how well it works for dynamics, you were expecting for us to try to actually render those dynamics?
The very first thing anybody is going to try is to shatter something, pack it, and sim it.
And then bamf! it doesn´t render properly, because you lost your inside and outside group…not very logical, is it?
Or maybe, we are supposed to unpack every time before render. Which I can live with, but I would expect someone to confirm it if that´s what I gotta do.

per primitive/per point attributes are kept inside of packed primitives and are properly accessable in the shader through Bind VOP/Parameter VOP as it's the case of unpacked geometry as well
the same goes for shop_materialpath attribute as mark mentioned so it uses correct material
on top of that you can get attributes of packed primitives through renderstate() as mark mentioned as well

that already gives you lots of power to vary each packed primitive's shader individually without unpacking
with a little bit of expectation from you to think ahead and prepare your packed primitives properly

additionally you can always unpack the packed fragments change what you need and pack them back

the fact that you loose groups is not a big deal if you've already assigned materials to them before packing them for dynamics

I'm not saying that it wouldn't be great to be able to override materials per group inside of packed primitives, but at the same time it doesn't stop you from rendering packed primitives at all

additionally what I miss in packed primitives is the ability to promote attributes to/from them while packing/unpacking
so that any attribute from packed primitive like Cd, pscale, etc can be composited with the same attribute on the geometry (packed inside) when unpacking it, so you can chose if it should replace, add, subtract, miltiply, divide, do weighted average, do nothing…
the same for packing, just extract that attribute like attribromote does First Match, Max, Min, …

and as well attributes applied to packed primitives like Cd are not visualized in the viewport, that would be cool as well

I just realized the same issue until i unpacked my primitive after simulation and got all the groups back and now i can do what ever i want to do with those groups.

Does it help ?

You can also cheat the system…. ops:

Assign materials before packing, promote attributes to points, fuse all points to their center location with foreach and transfer the attributes ontop of the packed primitives.. ops:

Netvudu
Well, don´t get me wrong, Mark. I appreciate both your explanation and the packed geometry feature, but…seriously, no matter how I look at it, it looks as bad planning.
I mean…how long, after you guys told us how cool packed geo is and how well it works for dynamics, you were expecting for us to try to actually render those dynamics?
The very first thing anybody is going to try is to shatter something, pack it, and sim it.
And then bamf! it doesn´t render properly, because you lost your inside and outside group…not very logical, is it?
Or maybe, we are supposed to unpack every time before render. Which I can live with, but I would expect someone to confirm it if that´s what I gotta do.

Mmmm not trying to defend Mark here but, usually before shattering and simming you have the look dev done, or at least the shaders assignments, which are saved in shop_materialpath. An attributes are kept in packed primitives. So what I can see is, more than a problem in packed primitives (ans there are issues indeed), is more a workflow issue.
Is kind of the same situation as when you use polysoups.