Nulls and Parenting

Would love to  have this for easy scene management.


Object list should allow parenting and nulls in order to make organization possible.  Once the Object list has 100 objects, its no longer usable.

I completely agree with you. This feature would help a lot.
Also, some means to set pivot points to those nulls would be very handy too.

FYI,

You can have parent/child using "Bone > Hierarchy"

Select the objects you want to parent/child > Combine
Open "Bone > Hierarchy", Reroot the parent(mesh), then drag/drop children to that parent root. Remove default bone root.
Exporting via .dae will preserve parent/child Hierarchy (well, at least it does when going to Blender.

Unfortunately at the moment, you can only access the "bone > hierarchy" (and other hierarchy commands, via the visual tools window)

I tried using Nvil's bones a couple of months ago, but they were too cumbersome to work with for such simple tasks as group transformations. I ended up completely disabling them along with the mesh functionality. Also, I don't think bones can be used for scene organisation. We really need some sort of containers and multi-level hierarchy of Object List. Null groups would fit perfectly here I think.

As a side note:
Object groups from the Scene Explorer provide similar functionality to null groups, of course only when it comes to group transformations and persistent group pivot.

I tried using Nvil's bones a couple of months ago, but they were too cumbersome to work with for such simple tasks as group transformations.

There is no need to create /work with bones, I only use the Hierarchy system for the mesh. Although as I mentioned, it is a pain having to use the visual tools window to access that.

I ended up completely disabling them along with the mesh functionality.

At one time I went in the opposite direction and only ever had one object in scene (all added objects where combined). I found it a way around selection issues/problems.

We really need some sort of containers and multi-level hierarchy of Object List. Null groups would fit perfectly here I think.

I will certainly agree that better scene organization is needed. Unfortunately IStonia made various changes but did not (IMHO) really look at the changes from a user point of view.  (one simple example. Why do we have 2 object lists? One called from visual tools, and one in scene explorer(that can be split off). The visual tools object list does not have all the functionality of the other.)

Its just the natural development of the application, as it improves, some things become obsolete.

Its a one man show with a constant public beta...so I cannot complain.  We have more input here then users on the beta forums of Autodesk apps. ( i am a member)

Its just the natural development of the application, as it improves, some things become obsolete.

Anything obsolete should be removed completely.

Its a one man show with a constant public beta...

It is the "Constant Beta" that is giving me concern.

When Nvil 1.0 (licensed version) was released, I asked if new features would be stopped (for a few months) and time spent just on bug fixing/ optimization. It would give time for full testing/bug reports. But IStonia would not do that.
We are now in a situation with many builds of Nvil, but none that have been fully(as possible) tested, so no build that can be shown as being as bug free/stable as possible. It is why we have seen on forum new users finding bugs they expected would of already been found and fixed. But how can anyone beta test an application that is updated every week(or so) with new features, undocumented bug fixes and undocumented performance improvements, as each time you get new features and undocumented changes, the testing needs to start over again.

So here we are now, almost 18 months after official release of V1, with various underlying issues, and a developer who, due to work commitments, cannot find the time to fix those underlying issues fully/correctly.

...how can anyone beta test an application that is updated every week(or so) with new features, undocumented bug fixes and undocumented performance improvements, as each time you get new features and undocumented changes, the testing needs to start over again.

I'm in agreement. Some kind of project bug/request/feedback tracker system would be really nice.  I know we're still only 6 months into the life of the NVil x64 builds, but it sometimes seems like the development occasionally goes in circles with old bugs popping up again, and it's really tough to mentally keep track of what's been fixed, reported, requested, and so on from week to week.  I can't imagine it's much easier for the dev.  I don't want to discourage Istonia in any way, because I'm very fond of NVil and am forever impressed at the enormity of such a one-man project and the skill required to create such a thing.  Also, it unquestionably does a great many things very well.  On the other hand... I would really appreciate having some kind of basic grip on where it's currently being developed in any given month.  In a way, I almost wish I could be a part of a pool of people paying something monthly to hire Istonia full-time to further push continuous development, or perhaps a Kickstarter backer... but unfortunately, I'm only one underpaid artist, so there'd have to be a small army of likeminded folk.  Anyhow, I guess I'm getting off the subject a bit...

I know we're still only 6 months into the life of the NVil x64 builds, but it sometimes seems like the development occasionally goes in circles with old bugs popping up again,.............

But is it bugs or incompatibility with windows x64?

I have seen and reported various bugs in Nvil running on X64, but not all are seen when same build of Nvil is running on windows x32.

I have had various e-mail exchanges with IStonia concerning the .dll(s) being loaded by Nvil, but I get nowhere, as he does not see the same .dll(s) being loaded on his setup (well he would not, considering I am on x64 and he is on x32).

Just simple example.
Nvil loads 2 .dll.
msvcr80.dll (Visual C++ 2005)
msvcr90.dll (Visual C++ 2008)
[the same dll from 2 different libraries. Both those .dll should be installed/shipped with the application]

So checked to see what prerequisites SlimDX installed. Found it installed "msvcr90.dll". However, SlimDX installer only installed 32bit version and it did not even check if 64 bit version was available on system. Nvil loads 64 bit version from side_by_side libraries(winsxs folders), but is completely different version to one installed by slimDx, so probable dll conflict.
On checking msvcr80.dll. Nvil does not install or ship with that .dll, it is loaded from side_by_side libraries, so again probable dll conflict.