Dunno when it happened, but lately the geo viewer became quite useless, as now non-geo COMPs block their children geometry from being visible in the geoviewer.
So having a geoviewer at / and these nodes:
/geo1
/container1/geo1
you’ll not see the geo1 in the container1 (but there are various reason why you would put a geo COMP inside a panel COMP).
e.g. let’s say container1 is a Component which provides various simple geometries. It also has a UI. So in order to show it’s geo in the geo viewer, I would need to make the top level COMP of the component a geo COMP. But I want all my components to share the same COMP-type as the top level node (a container). Besides, if I would make the top-level COMP a geo COMP, then any contained panel will not be visible if looking at the component’s parent panel.
All this worked fine a couple of weeks ago. Am I missing something?
To see the geometry inside a Panel Component, you must change the path for the Geo Viewer to the panel component.
In you example, if you change the Geo Viewer’s path to /container1, you will see /container1/geo1.
The Geo Viewer looks in its current location and down thru the hierarchy for objects and SOPs with their display flags on. Panel Components are exempt as they do not have display flags. Some control panels you create may have geometry in them as part of the UI, this will keep them from being displayed in a 3D view.
I know that I can set the viewer to show the geo in container1, but this will show me just that geo. The big problem is that I can’t see the whole geometry (spread across various sub-networks), unless everything is located in geo COMPs. As described above, there are various reasons why you wanna put some geo COMPs into a panel COMP.
Imho a panel container should also have a display flag (maybe just in list view, off by default, no transforms needed). Even without a display flag on panel COMPs I don’t see the possibility of having geometry in a panels UI a big issue. Can’t just disable that geometries display flag in such a case?
Besides, this seems like much less frequent scenario compared to building components which provide non-UI related geometry (but need their top level COMP to be a panel).
PS: Besides being able to see a component’s panel in the parent COMPs panel, another reason for top level panel COMPs in all components is that you (always) only need to create a container COMP and set the clonestring to create a clone. No need to first find the matching COMP type … makes designing/unsing a component system much easier.
I’d build my own viewer based on a render TOP …, but as there are no xform handles (yet), this isn’t an option.
I know touch is officially still beta and things might change and break existing files, but as there’s no workaround, this change is a big problem and it made all my files pretty unusable. So please let me know if there’s a chance that this behavior will be re-enabled soon (display flag on panel COMPs) or that 3d-handles are pretty close to being implemented (preferred)
Hey Achim, Panel COMPs are going to be separate beings from Object COMPs for now, so this is a limitation you’ll have to workaround. No timeframe for 3D handles right now, we are working towards a new experimental build to be released in the next few days, so we are slammed getting that ready for you all.
Hey Ben, the thing is, there is no possible workaround. The foundation of my setup is designed around the old behavior. Hope the fact that other people asked for 3d-handles as well will, together with this report, push 3d-handles (and/or a viewport COMP with handles) high up on the agenda
