NVil Forum
General Category => NVILL Discussion => Topic started by: molebox on March 09, 2013, 07:35:43 pm
-
http://youtu.be/IbbFVOhjREk
This works strange and uncomfortable.
Maybe better as:
When you pressing button "New Group" (better to change on "Group selected) - all checked will move into new group.
-
agreed Maya has a button for both group selected and empty.
-
It is improved. When you create a new group, both scene selected and checked objects will be included into the new group.
-
Thanks IStonia, it is much better.
-
Could somebody please explain me the conceptual difference between Subobject Groupand Object groups and why it is important to have both concepts in Nvil?
To me all this hierarchy stuff seems totally unnecessary for a modelling only program and really in the way when thinking of simplicity. I'd like to see a convincing example why one needs this. In Silo one can group all similar entities: Verts, Edges,Faces and Objects. All within one simple interface - beautiful.
-
groups are actually very useful for modeling, and not just scene organization, since they can have there own origins that can be used to rotate or translate multiple objects around.
-
I get the impression that sub_object groups where added at a later time to the object groups and never fully integrated.
For example:- I have a polygon_group and a vertex_group. When working with those, I go into polygon selection mode, bring up the polygon_group UI, select the group. If I then use the visual-tools, the group UI is automatically removed, while the group UI is enabled, hotkey tool function will not work, you need to manually remove the sub_object group UI first.
If changing between sub_object selection, the group UI is automatically removed, so you need to keep re-enabling the group UI even when simply trying to change between sub_object group types.
I do think the sub_object groups need better integration. At the moment they are (IMHO) a bit of a pain to work with
-
groups are actually very useful for modeling, and not just scene organization, since they can have there own origins that can be used to rotate or translate multiple objects around.
Thanks Passerby,
would you see a reason why sub-object groups of items could not have custom origins?
I'm not against groups, definitely not but I simply don't get why there's two grouping features.
-
I do think the sub_object groups need better integration. At the moment they are (IMHO) a bit of a pain to work with
That's funny, I come along quite well with the sub-object feature but I don't even have an idea what molebox is doing in his threadstarter-video. I think this all needed to be simplified and unified.
-
I think this all needed to be simplified and unified.
How?
To simplify, that could imply removing current options, which is not something I would like. To unify, place all groups into the scene_explorer?, yes, that I would like.
If the object and sub_object groups are to kept in separate UI. Then I would like to see the sub_object UI to be floating/dock-able, that can be left open during working with/on the sub_object groups.
-
I don't think that simplification implies feature removal.
I was talking of redundancy. Here's how things work in Silo.
As simple as it gets.
(http://i.imgur.com/0GGLGqD.gif)
-
How about naming /re-naming a group? Is that seen as complex?
I like to name a group, not have a possible long list of similar name groups.
-
In Silo you can give those groups any name by doubleclicking them.
One then can no more see that which type of group that is but one could easily solve
that problem with a small icon for the group-type.
-
In Silo you can give those groups any name by doubleclicking them.
I was not saying you could not rename them in Silo, just asking if you think naming/re-naming is complex.
One then can no more see that which type of group that is but one could easily solve
that problem with a small icon for the group-type.
Currently, the sub_object groups in NVIL are context sensitive, so while, as example, in vertex mode, only vertex groups are selectable. Is that complex, or possibly a better solution?
What I am struggling with is your putting forward simplifying. I asked how. Please explain.
-
In Silo you can give those groups any name by doubleclicking them.
I was not saying you could not rename them in Silo, just asking if you think naming/re-naming is complex.
I don't quite follow. In Silo it is as easy as renaming a folder in Windows Explorer.
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. Also I mostly need polygroups because these groups are transferable to Zbrush.
Currently, the sub_object groups in NVIL are context sensitive, so while, as example, in vertex mode, only vertex groups are selectable. Is that complex, or possibly a better solution?
What I am struggling with is your putting forward simplifying. I asked how. Please explain.
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. So yes, I like that system - it might need an initial understanding but I find it a very powerful way of filtering.
For a useful grouping feature I think that on the model one should only have access to groups of the current subobject type, if at all. From the GUI element which holds all groups one should be able to select groups of all subobject types at all times. Selecting this entry automatically switches the current subobject type and highlights the group in the viewport.
-
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 (http://<a href="http://www.screencast.com/t/T56GG5wYIsGT">Untitled</a>)
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?
-
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?
Agreed. Same goes for the split command.
-
And 'combine' etc.
basically anything that can be undone should not have a popup asking for confirmation.
-
Also I mostly need polygroups because these groups are transferable to Zbrush.
Is this possible in NVil? If so please teach me how thanks.
-
Is this possible in NVil? If so please teach me how thanks.
The feature has recently changed its place in the program. It's now found in the Scene Explorer.
Make sure to enable groups in the .obj exporter.
-
Hi IStonia,
in the new groups implementation in the Scene Explorer every newly created primitive / object automatically creates a new object-group. That's not what I would expect - is there a way to avoid this?
-
It does not create a new object-group. It just put the new object under the fixed 'Object Groups'. What is your expectation?
-
It does not create a new object-group. It just put the new object under the fixed 'Object Groups'. What is your expectation?
I would expect any type of subobject not to appear in the Group section in any way for as long a they are not actually grouped. If there's ten cubes in a file they should appear in the object list but not under groups, unless they got grouped through User input.
I frankly also preferred if a Layout closer to what Silo offers was used so that one gets an instant overview. These separate hard coded page-tabs which can not even be shown at the same time are not as user friendly in my opinion.
I found combining these list better in this instance, but getting rid of those static tabs was generally desirable also in other places of the program (e.g.Scene Materials and Material Library).
(http://i.imgur.com/0GGLGqD.gif)
-
Is this possible in NVil? If so please teach me how thanks.
The feature has recently changed its place in the program. It's now found in the Scene Explorer.
Make sure to enable groups in the .obj exporter.
it is not working for me:( I grouped the faces and then exported it in .obj format and still zBrush would not recognize the groups.
-
it is not working for me:( I grouped the faces and then exported it in .obj format and still zBrush would not recognize the groups.
Can you create a very simple box obj file from a program that zBrush recognize its grouping and send it to me so I can check the difference?
-
Personally how I'd like to see this is to have groups listed underneath the object they're a part of , together with meshes in the outliner. When groups encompass multiple objects, list it in a seperate 'groups' list.
Here's a quick overpaint of a blender screenshot:
(https://dl.dropboxusercontent.com/u/17715/vw_groups.png)
What would also be very cool is if a radial menu could automatically be populated with the first 8 groups you create, but that's a seperate issue.
-
it is not working for me:( I grouped the faces and then exported it in .obj format and still zBrush would not recognize the groups.
Can you create a very simple box obj file from a program that zBrush recognize its grouping and send it to me so I can check the difference?
Here.
-
Actually, looking at my overpaint, I was too quick. I don't want the groups to be a child of the mesh, I want them to be listed underneath the object, just like the meshes are.
edit: there, I modified it to look better.
I still want less intrusive icons and different colours, this is just a quick mockup for functionality. What do you guys think?
-
Is this possible in NVil? If so please teach me how thanks.
The feature has recently changed its place in the program. It's now found in the Scene Explorer.
Make sure to enable groups in the .obj exporter.
it is not working for me:( I grouped the faces and then exported it in .obj format and still zBrush would not recognize the groups.
Polygroups import fine to Zbrush.
As said before - one needs to configure the .obj-exporter in Edit/Options/File Format Options to export Polygroups.
-
As said before - one needs to configure the .obj-exporter in Edit/Options/File Format Options to export Polygroups.
There is no option in .obj exporter to export poly_groups.
-
Sorry about that, I had that wrong in memory.
That said - it still works on my side, Zbrush can see Polygroups in .obj's exported with Nvil.
-
NVIL exports poly_groups by default (although it was broken, but now fixed).
The only way I can see a possible problem is if option" Regroup polygons by meshes" is enabled, which would probably change the exported poly_groups.
-
Sorry about that, I had that wrong in memory.
That said - it still works on my side, Zbrush can see Polygroups in .obj's exported with Nvil.
can we see your setting in the File Format Option or what steps are you doing to make it possible to see poly groups in zBrush. Thanks
-
Arvin, I check your obj file and can't see any difference in terms of format. Can you show me another obj file exported from NVil whose polygon groups do not show up in zBrush. You can just import that file into NVil then export it.
-
was able to make it work, hmmmmm
anyway thanks for the helping:) I don't know what I did but it works now:)
-
Personally how I'd like to see this is to have groups listed underneath the object they're a part of , together with meshes in the outliner. When groups encompass multiple objects, list it in a seperate 'groups' list.
Here's a quick overpaint of a blender screenshot:
(https://dl.dropboxusercontent.com/u/17715/vw_groups.png)
What would also be very cool is if a radial menu could automatically be populated with the first 8 groups you create, but that's a seperate issue.
I would also like it if it looks like this:)
-
I've been thinking about it more, and a few more things I think could be included in the scene explorer:
creased edges, listed underneath the object, grouped by crease value. Ofcourse these would only show up when there are creased edges.
Also underneath the object, the material (if adjusted from the default), clicking on which would take you to the material editor.
Also, saved custom pivots and orientations.
A Workplane item with all saved workplanes underneath it (much like creased edges, this would only show up once you've used the workplane. Say you've aligned it to a selection, that workplane will show up here underneath a main 'Workplane' item, giving you the option to save it for later.
I'd like to eliminate a lot of the loose windows I need right now, and the Scene Explorer seems like the perfect place for these things.
An option to automatically show and expand the selected object (and collapse the rest?) would complete it, in my opinion. This way you always see information relevant to the selected object. Given that Voidworld's a pure modeling app, scene management isn't as important as it might be elsewhere.
I'll make another mockup once I'm done thinking about this. Any feedback would be most welcome!
-
The problem is that an object can appear in more than one group.
-
Then, much as it will now, it will just show up multiple times right? I don't see that as a problem as such. But I see your point, and I suggest layers for this type of organisation, where objects can only be in one layer.
Then groups can be displayed seperately under a groups item, what do you think?
Thanks for the feedback, I hadn't considered this.
-
I've been thinking about it more, and a few more things I think could be included in the scene explorer:
creased edges, .......................Also underneath the object, the material ...................Also, saved custom pivots and orientations.
A Workplane item with all saved workplanes underneath it
Although that may work when building a single object, or few objects in a scene. What about a scene with, for example, 100+ objects containing 150+ meshes, with 60+ materials and 20+ saved work_planes?
I would see that as a bit of a nightmare with all placed in one window.
Given that Voidworld's a pure modeling app, scene management isn't as important as it might be elsewhere.
Again, that would come down to what number of objects/materials etc are in the scene.
-
That would look like this:
-object
-mesh
-mesh
-creases
-0.25
-0.75
-materials
-object
-object*
-workplanes
And then creases, materials and workplanes woulddn't be there by default, only if there'd be information to display there.
You'd collapse everything but what you've got selected in the viewport. My suggestion mentioned that I'd even want to this to (optionally) be done automatically.
You pretend as if the problem here isn't that you're working with 150+ meshes, but that we're also listing the workplanes and materials. That to me is crazy.
Without layers, 100+ objects will always be messy, you need some organisation. I just feel some organisation should be applied to the many seperate windows as well, but in the spirit of Voidworld's customisability I see that you may want things set up differently from me. I certainly don't want to constrain things to one certain way of working.
*(and on and on. layers should be used for organising, so it'd actually be clearer than it would currently be)