Object Group

What I am struggling with is your putting forward simplifying.

At the beginning of the Voidworld development in the Polycount forums several (former)Silo users took part. Taking the striking simplicity of Silo as a template and improving on it for quite some posters was a driving idea. Yes, I am not interested in a powerful, yet considerably complex to use Nvil - if I wanted such I could also switch to Modo.
Users coming from other apps often can not imagine how much one can condense things without actually sacrificing functionality.

I don't quite follow. In Silo it is as easy as renaming a folder in Windows Explorer.

I simply asked if you thought naming/renaming groups as complex.

In Nvil I don't use the Scene Explorer. It in its current implemention indeed seems not straightforward enough for what I want from this program - I typically only have a few items on screen. I don't think it's a good idea anyway to build scenes with many parts and deep object-hierarchies in Nvil.

I do build models with lots of parts and do use some object group hierarchy. I do not see that as a bad idea, but everyone is welcome to their own opinion.
 

Also I mostly need polygroups because these groups are transferable to Zbrush.

I use mainly vertex groups. Maybe someone else uses mainly edge groups?

To me the concept of context sensitivity is one of the most successful ways to make a Subdivision Modeller slim. It was me who suggested Istonia to organize menus in a way that entries are dependant ofthe currently active subobject mode.

Probably why the sub_object groups are context sensitive then.

So yes, I like that system - it might need an initial understanding but I find it a very powerful way of filtering.

But not for groups.

At the beginning of the Voidworld development in the Polycount forums several (former)Silo users took part. Taking the striking simplicity of Silo as a template and improving on it for quite some posters was a driving idea.

So why are the groups set up as they are? Did no one mention groups? I know they have been the way they are for at least 12 months.

Sorry but you tend to twist my words - I don't like wasting time with conversations of that nature.
Of course the process of renaming items is nothing one can consider complex. I at least don't and did not write or imply this.

Groups of all item types in my opinion should be availble in just one common interface.
So that you could use your vertex groups or any other type from just one place in the program.

Objects with deep hierarchy:
The limitation is is that Nvil can not hold millions of polygons and that all hierarchy  is lost at export time.
I therefor suggest taking Nvil as what it currently is  and that would rather be working on per component basis
and taking care of complex nesting in an output-application.

Finally look at the animated gif again that I posted.
Silo is perfectly context sensitive in Menus and in the viewport. But can you discover that sort of filtering in my gif?
What's your point then?  I never advocated context sensitivity in an Editor which stores groups of Subobjects.
Anyway, I'm out.

Well, as far as I am concerned, object hierarchy could be removed and I could use poly groups instead. But as they must of been requested at some time, I would not ask for them to be removed.

Well, as far as I am concerned, object hierarchy could be removed and I could use poly groups instead. But as they must of been requested at some time, I would not ask for them to be removed.

Not every feature and every implementation is a result of user requests.
Object hierarchies quite certainly are still in place because Voidworld long ago was planned as an animation package. Here all sorts of parenting and stuff makes sense, but now one actually would not need these features any more and it would be good to remove them.

The Mesh-Item is also a hierarchical relict of a time when the program should develop into something quite different. Now one could easily come along with just Verts, Edges, Polygons and Objects (again as Silo does it) - it imo would simplify things considerably if  Mesh was completely abolished from the application. It would have no disadvantages. Clearly my greatest wish for future versions.

One thing where Nvils object handling really is in the way is also in duplication.
The app offers long Excel lists of objects, yet simple duplication is only possible
for polygons and objects. Again Silo is much faster and more streamlined. All subobjects
types can easily be duplicated and appear in the Object stack. See here


Url was not working - so I paste it here as well: http://www.screencast.com/t/T56GG5wYIsGT

Object hierarchies quite certainly are still in place because Voidworld long ago was planned as an animation package. Here all sorts of parenting and stuff makes sense, but now one actually would not need these features any more and it would be good to remove them.

The thread you mention over at Polycount, was this not mentioned in the 2+ years long thread?
I ask because if it was, I would like to see the response from IStonia. If it was not, then why wait until now?

Starting to remove features after full release does appear strange to me. Such changes (IMHO) should really of been made in beta (pre full release).

Removing object hierarchy is not a simple task as I have mentioned before. It is part of the foundation.

The thread you mention over at Polycount, was this not mentioned in the 2+ years long thread?
I ask because if it was, I would like to see the response from IStonia. If it was not, then why wait until now?

Yeah, this topic was discussed before, also in the polycount thread. A change seems to be a lot of effort.

Starting to remove features after full release does appear strange to me. Such changes (IMHO) should really of been made in beta (pre full release).

It was no removal but just a replacement with another system. This happens all of the time in any software. I had no problem whatsoever with such.

Removing object hierarchy is not a simple task as I have mentioned before. It is part of the foundation.

Yes I indeed remember you stating this before. My resulting question would be - how do you plan dealing with that topic in the long run? Will the underlying concept stay the way it is?

Removing object hierarchy is not a simple task as I have mentioned before. It is part of the foundation.

Yes I indeed remember you stating this before. My resulting question would be - how do you plan dealing with that topic in the long run? Will the underlying concept stay the way it is?

It is likely to stay that way. First, due to the amount of work, I can't aford to change it. Second, it does provide some convinience to animate an object with complex struture to see the result. From a file a user sent me a while ago, I can see he used it.

Thanks IStonia!
Just to make sure: This means Nvil will for forseeable future have objects as well as meshes. Correct?
Does the underlying architecture also make two separate grouping features necessary?
Would the architecture forbid having vertices, edges and polygons (or groups of such) listed in
a common Scene Tree - as shown in my gif and video?

cheers, H.

Thanks IStonia!
Just to make sure: This means Nvil will for forseeable future have objects as well as meshes. Correct?

Correct.

Does the underlying architecture also make two separate grouping features necessary?
Would the architecture forbid having vertices, edges and polygons (or groups of such) listed in
a common Scene Tree - as shown in my gif and video?

I can intergrate the subobject groups into the current object group tree view in the Scene Explorer. What I am going to do is to have 4 fixed top nodes: Object Groups, Polygon Groups, Edge Groups and Vertex Groups. All the groupings will happen under the related top node.

I agree with Polyxo's video. I'd like to be able to
a: have seperate verts and edges (also to create these from scratch) and
b: make duplicating less difficult. Maybe add a 'duplicate (no dialog)' tool we can hotkey ourselves, or even seperate tools, one for each option in the dialog?