“^geo1” worked fine.
“^geo1 ^geo2” didn’t work.
“^geo[1-2]” didn’t work too.
The documentation for Render TOP says
“Geometry geometry - Specifies which geometries will be included in the rendered scene. Example: geo* ^geo7 will render all Geometry components whose names start with geo except geo7.”
but “geo* ^geo1” doesn’t work.
The Problem with patternmatching is that they are not logical combined but stand for themself.
So chan* will als return chan1, and then ^chan1 will, aditionaly, return all channels except chan1
So ^chan1 will return chane2, and ^chan2 will return chan1.
In the case of the second, simply remove the geo* and you will get the result of ^geo1
Thank you. I know that. I wanted to tell Render TOP documentation that geo* is not necessary.
I want to know why “^geo[1-2]” work well with CHOP but not with Render TOP.
One other workflow I use a lot for dynamic matching of objects is to use a op Find DAT and do my complicated inclusion / exclusion logic there, because you have a lot of matching fields to use and also python callbacks to do any custom filtering you want.
then you can reference the results of the op find dat easily in the geo parameter of a render top like this:
op('opFindDat').col(0)[1::]
also works great for toggling the contribution of lights dynamically too!
Great tip! I didn’t know parameters evaluated DAT rows/colums directly to a string like that.
I have been using an unneeded workaround in the form of " ".join([cell.val for cell in op(‘opfind1’).col(0)[1:]])
Interesting that this works though. Because if I take a DAT column in a script, each item in the list is a cell object (prior to the .2023 version where the cell() method has an option to return values instead), and I have to iterate over the list to get the strings contained in the cells with .val
