If you use a ConfigurePrimitive LOP to change some prims' Draw Modes to Bounding Box, merge said prims, then plug the merge into an Instancer LOP, the Draw Mode reverts back to full geo. Technically in the Scene Graph Tree the Draw Mode designation disappears altogether, but in the viewport the prims revert to full geo.
Is there a way to inherit the Draw Mode from the prototype prims?
Inherit Draw Mode when using Instancer LOP
3534 5 0-
- Hamilton Meathouse
- Member
- 209 posts
- Joined: 11月 2013
- オフライン
-
- mtucker
- スタッフ
- 4559 posts
- Joined: 7月 2005
- オフライン
-
- Hamilton Meathouse
- Member
- 209 posts
- Joined: 11月 2013
- オフライン
-
- mtucker
- スタッフ
- 4559 posts
- Joined: 7月 2005
- オフライン
There are a couple of bugs here, but they aren't quite as you describe.
For the first problem, using draw mode requires a continuous hierarchy of “kinds” set on all prime up the hierarchy to work properly. On the Instancer LOP you should set the Primitive Kind parameter to “group”. At this point the true bug in the Instancer LOP rears its head, which is that the Prototypes child of the instancer should also be set to “group” Kind, but it is not. If you append a Configure Primitive LOP and set /instancer1/Prototypes to “group” kind, then you get bounding boxes. You can easily see that the kind hierarchy is “broken” and that the draw mode won't work by looking at the scene graph tree and noticing that the “Draw Mode” column doesn't have the draw mode selection menu on your prototype primitives.
The sphere not being used as a prototype is because in the Prototype Primitives parameter on the instancer, you have specified `lopinputprims('.', 1)`, which evaluates to the “last modified primitives” of the merge LOP. If you look at the merge LOP you can see that only the cube and cone are in that list of last modified prims. This is a bug, and the merge LOP should be include the sphere in that list too. But this bug is easy enough to work around by changing the Prototype Primitives parameter to “/*”.
I'll fix the issue with the Merge LOP and the Prototypes kind authoring in the instancer LOP, but for now you should be able to work around these problems as described. Thanks for the bug reports!
For the first problem, using draw mode requires a continuous hierarchy of “kinds” set on all prime up the hierarchy to work properly. On the Instancer LOP you should set the Primitive Kind parameter to “group”. At this point the true bug in the Instancer LOP rears its head, which is that the Prototypes child of the instancer should also be set to “group” Kind, but it is not. If you append a Configure Primitive LOP and set /instancer1/Prototypes to “group” kind, then you get bounding boxes. You can easily see that the kind hierarchy is “broken” and that the draw mode won't work by looking at the scene graph tree and noticing that the “Draw Mode” column doesn't have the draw mode selection menu on your prototype primitives.
The sphere not being used as a prototype is because in the Prototype Primitives parameter on the instancer, you have specified `lopinputprims('.', 1)`, which evaluates to the “last modified primitives” of the merge LOP. If you look at the merge LOP you can see that only the cube and cone are in that list of last modified prims. This is a bug, and the merge LOP should be include the sphere in that list too. But this bug is easy enough to work around by changing the Prototype Primitives parameter to “/*”.
I'll fix the issue with the Merge LOP and the Prototypes kind authoring in the instancer LOP, but for now you should be able to work around these problems as described. Thanks for the bug reports!
-
- Hamilton Meathouse
- Member
- 209 posts
- Joined: 11月 2013
- オフライン
Ah thanks for the work-around.
Just throwing this out there: `lopinputprims` immediately gives the thought that it's all input prims. Maybe we can change that function to behave as expected (eg: get all input primitives), and have a separate function for modified prims (`lopmodifiedprims` for example)?
Just throwing this out there: `lopinputprims` immediately gives the thought that it's all input prims. Maybe we can change that function to behave as expected (eg: get all input primitives), and have a separate function for modified prims (`lopmodifiedprims` for example)?
-
- mtucker
- スタッフ
- 4559 posts
- Joined: 7月 2005
- オフライン
lopinputprims is actually a shortcut way of invoking loplastmodifiedprims with some common arguments. So the word “input” is important, and the fact that it should be a short function name is important (lopinputmodifiedprims would be the alternative). Also it's too late to change the behavior of an existing expression function, or every hip file that uses it will break. And I'm not sure there is actually much call for a function that returns “all input prims”, as that's equivalent to just using a pattern of “*” which is much more concise…
-
- Quick Links