Nvil is slow.

Another workflow tip is splitting the object into smaller chunks and only smooth the object you are working with.

I made another test.
I have this detail of model that has 131k polys.

And open/save it in diffrent applications.

Nvil
Open - 3 MIN
Save  -20 sec

Cinema
Open - 2 sec
Save - 1 sec

Modo
Open - 3 sec
Save - 3 sec

As you can see Nvil also have horrible result

Also working with this 131k model is VERY hard, becouse everything is very slow....

Just had a quick look at that (I downloaded the file).

It took 7 seconds to load in Nvil on my setup (single mesh)
Looks like a lot of time spent when loading obj when option is set to "Divide into objects"

The model itself, not sure what you are doing. A quick check shows the model has 571 overlapping faces. Looks like sub_d added to poor geometry.

-------------------

I removed the overlapping faces(which where edge loop problems from sub_d). Saved as .obj. That now loads into Nvil (with "Divide into Objects" on) in approx 25 seconds. Still longer than I would expect. The same file as a .dae, loads in 4 seconds.

IStonia pleas, fix the functionality, I made these two projects in Nvil and in the end when polycount increases it become very hard to work, Nvil Become very slow... It works good on small projects but on projects that have more than 300k  it works very bad... I love Nvil a lot but that thing makes me search for another application to work.

It is not an easy task. NVil is written in .net language C#. So it can only have a fraction of the speed of other apps that are written in C++. I may still have some room to improve it. But it needs time and the end result may not be much better.

This fraction depends on amount of polygons?

No. It's hard to tell the difference between 0.01 second and 0.1 second. But it would be obvious when it is 1 second and 10 second. The more polygons you work on the more time it needs.

Good, pleas fix it if it is possible, Nvil is GREAT and I want to work in it, but this thing makes me sad. I tried to model in Max and Xsi but Nvil is the best in modeling. And as I think the only one thing is critical now for Nvil it is perfomance. I'll hope you can fix it)

Once again, I asking you pleas make something. I have big troubles working in NVil, I have to wait about 10 minutes to import 500K .obj model... Also have to wait 5 minutes when save it to obj...
I'am VERY VERY SAD....

I will look into that once I finish the current spline related issue.

Thank you, I'm waiting it impatiently!

Also if I want to combine/split objects that have in total more than 50k polys I have to wait no less than 1 minute.

Today I had to export this model to obj, it has 796k polys, and I had to wait 12 minutes, I have i7 and 28 GB RAM. C4D or Max made it for about 45 sec.
This and other speed limitations turns Nvil into lowpoly modeller, becouse work with high poly models is VERY VERY HARD   

It is probably at the base of NVil, but which mesh data structure is it using? I just read a paper on an allegedly easy-to-use halfedge data structure that might lead to increased performance and less memory usage compared to CGAL or OpenMesh. Though it was tested against an old OpenMesh version (2.1, current: 3.0) http://graphics.uni-bielefeld.de/publications/imr11/ The sourcecode is available in C++, but maybe there's something useful.
Here's a link to the paper: http://graphics.uni-bielefeld.de/publications/imr11.pdf

If the underlying data was changed, all the algorithms(tools/functions) that manipulate that data would also need to be changed.

The problem with Nvil .obj export is, IMHO, a problem with how it combines(merge meshes) all the objects in the scene before output (the "Combine/merge mesh" can take a long time). I have never seen that done before, and do not understand the reason such a method for export is made.

All the other .obj exporters I have used, export objects as objects / vertex groups.

I avoid exporting to .obj (from Nvil), and use .dae


 

If the underlying data was changed, all the algorithms(tools/functions) that manipulate that data would also need to be changed.

I'm aware of that, but I still wanted to propose all possible means to make it faster. But then again, I could also just say "Do it again in C++", but I can imagine how much effort (in years) went into this current version. I still get the feeling there's a lot of garbage/leftovers in the architecture that may or may not slow Nvil down. I'm talking about sound manager and stuff like "GameStart" etc.

Another strange thing I noticed is, that if backface or frontface culling is enabled, NVil gets significantly slower. How's that?! In other engines it would speed up the viewer, since fewer surfaces are being rendered.

OT: I still see people on forums that purchase Silo, and the only things really keeping Nvil at bay are its speed and UV workflow, and of course its marketing (!!!). Otherwise it's more stable and has a ton more features. It's even cheaper. So not to get too off-topic, it's gotta be done something about the performance.