Nvil is slow.

On quick tests, vt and vn are OK.

For memory usage, there is improvement, but still using more than with the same scene as VWS or dae. I need to test more to re-check.

One problem that I missed before, is that .obj export will fail if there is an empty object in scene.(not a problem with empty mesh, just empty object). If select all objects in scene, which does not select the empty object, and use "export selected", then OK.
[if you need to create an empty object. Create an object (for example a box). select all polygons on object and use "Spit > Break into one new object". That will create a new object, but leave an empty object behind.(are empty objects useful in Nvil?)]

Steve OBJ dosnt really store things as effecitly as most formats, so it will always be a little more memory hungry.

Steve OBJ dosnt really store things as effecitly as most formats, so it will always be a little more memory hungry.

Passerby,

For that statement to be correct, Nvil would need to store data (for manipulation) in different formats.

When Nvil loads an .obj or .dae file, that file data is converted and then stored in a format native to Nvil. (if Nvil did store and manipulates different format types of data, I would find that very strange)
I do not know what data type Nvil uses internally, but for example, with wings, when you import an .obj file, that file will be converted to wing data and stored for tool manipulation, the .obj file data discarded and memory freed. You will always end up with approx the same (private)memory usage which ever format you load/import.

Do not misunderstand, personally, I do not care how much memory Nvil uses, if my computer memory (currently 16GB)starts running short due to large scenes(or even due to excessive memory usage by an application), I will add more(another 16GB) memory. But those running 32bit version, or with limited computer memory, low memory usage is important.

I have been looking at the old .obj importer on 32 and 64 bit.

When Nvil changed to 64bit, the amount of memory used(for .obj import) did increase, so the current extra memory usage I am seeing is not specifically due to the new .obj importer.
It may be a problem with the 64 bit version, or just as easily be the way 64 bit .net is handling memory usage.

I will find some time later to see what memory is freed from Nvil / .net when I use up system memory resources.
------------------------------------
No memory being freed from Nvil when system resource low, so the extra memory is being used.

Try this
http://www.digitalfossils.com/Download/NVil-Apr-25-14.rar

Still a difference between formats.

When loading same(test) scene as:-
vws 557,204k
dae 567,608k
obj 1,004,412k

If scene saved as single(combined) object, loaded from .obj as single object/mesh = 629,232k
If that combined scene loaded from .obj but divided into mesh(option in importer) = 948,292k
If that combined scene loaded from .obj but divided into objects(option in importer) = 1,035,164k


I will try to find some time to check loading that scene into Nvil on 32bit OS

When the imported object is divided, memory will be allocated for the new meshes. That why there is a memory usage surge. I have done what is needed to release the unused memory. But the releasing is controlled by .net runtime. You can't predict when it will happen and how much.

I can only think that the process you make in loading and converting the .obj file is what is taking all the extra memory. Net framework will only keep memory that is actually being or as been used.

But I have reported the problem, there is nothing further I can do on this issue.

Import problem
https://www.youtube.com/watch?v=Fa0xb2BJr2Q&feature=youtu.be
http://joxi.ru/dX9qU_3JTJBTU-gJuYo - file
http://joxi.ru/u39qU_3JTJAoU6VRhM4

Try this
http://www.digitalfossils.com/Download/NVil-May-07-14.rar