NVil Forum
General Category => Feature Requests => Topic started by: samardac on March 13, 2014, 06:00:48 am
-
Nvil become very slow if you have more than 200 000 polygons. I think it is the main problem of Nvil.... Pleas FIX it!
-
I have 670,000 polygons and 600 meshes without any lag.
Viewport performance is relevant to your Graphics Card as well.
I am using an Nvidia 460 card...pretty old card and it is handling things just fine.
-
I will be stress testing the app with my current project which is going to be 2m polygons minimum.
-
https://www.youtube.com/watch?v=tP1PTf3fcno&feature=youtu.be
:'(
-
Mason,
I have NVIDIA GeForce GTX 560 Ti, I7 and 28 GB RAM.
I have to wait 2 minutes to subdivide this model (80 000 polys).
And it is impossible to make subdive of level 2.
I found Nvil very slow in this way...
I think there is 2 weakness of Nvil at this time:
1. It is slow.
2. Lack of Help and tutorials.
-
(http://i.imgur.com/IzYoUMP.jpg)
Also see:- http://voidworld.cmcproductions.co.uk/index.php/topic,2231.0.html
-
Steve,
I tried this and a lot of other stuff that was recommended to me in one of topic I started about this. It is that thread that you posted...
But nothing can solve the problem. It makes Nvil a bit faster but it still stay very slow...
-
Have you tried the 64bit version, that should help remove any bottle neck around memory.
-
http://joxi.ru/eqghU_3JTJAWdI60sOI
-
Yep, I also have no *32 in task manager, so it looks like I use 64 bit version.
-
I just did a very random test on view performance with around 1 million polys. Ran on a laptop with 8GB RAM, i7 QuadCore @ 2.3 GHz, Nvidia Geforce GTX 675M.
View navigation was still ok. I tried a few different rendering options (hide edges on unselected, hide edges on view navigation, hide vertices/edges). But selection got really slow and unresponsive, even when just selecting objects. I didn't try selection options. Also the recognition of shortcuts didn't work that well anymore.
Because the test was so random, the video is quite long (~8min):
http://youtu.be/VU7VjGh-61o (http://youtu.be/VU7VjGh-61o)
[Edit]: Disabling 'Edit>>Options>>Reatime Selection Enabled' helps a bit.
-
Vaquero, that is what I'm saying about...
Also as I notice, if you have simple topology like you have in your test Nvil will more responsive. But if you have complex topology it will more slow. Like I say in my helicopter example it hase less polygons but topologŠ½ is complex and Nvil become slow.
-
Also, imagine you have to work always toggling subd... It is very hard... waiting for minutes to subdevide/unsudivide model...
-
I believe that the program which is based modeler, the first thing should be different good performance and flexibility
-
ya navigation is ok for me at 1m polys, but when i hit tab to toggle subd on and off, it takes forver
-
People,
I just made some little test.
This model has 74 700 polys, I toggle subdevision (3 level) in Nvil, Cinema 4d and Modo.
Nvil:
Subdivide - 1 minute
Unsubdivide - 40 sec
Cinema 4D:
Subdivide - 3 sec
Unsubdivide - 1 sec
Modo:
Subdivide - 1 sec
Unsubdivide - 1 sec
As you can see the result of Nvil is horrible :(
-
Until fixed, I suggest only smoothing the areas you are working on and not the entire scene. Single objects will be much faster.
-
Modo, O_o, seriously ?!
-
ya pretty much instant in maya as well about a second for 100k polys
-
Just so you guys know.
1x subdivision multiplies the polycount by x4.
2x subdivisions is x8
By default, Nvil uses 2x subdivision.
So a 100,000k mesh is going to be 800k.
-
Modo, O_o, seriously ?!
Are you disgusted by Modo? Not sure what this reaction means.
-
I did test
xsi 240 mil. tris
cinema 212 mil. tris
3ds max 160 mil. tris
maya 120 mil. tris
bledner 30 mil.tris ( edit mode object 20 000 polygons)
modo 23 mil. tris or 70 item mesh, 4 polygons in 1 item
i 3 year working in modo, and I'm very sorry that I spent time on it
-
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....
-
This is the detail that I used for test, you can try it by your self...
http://we.tl/YgZHGjag2j
-
Honestly, You could reduce the polycount of that piece by half.
I know it is off topic from performance of Nvil which could certainly use a boost in performance. As a general rule, this level of detail is only used at final rendertime. In a production pipeline they would ask you to model at a lower resolution with the expectation to smooth later.
Look at some wireframes of some famous breakdowns and you will see that they are working at a much lower resolution. Your current assets would not even benefit from being smoothed.
-
Also I made this test, using the same model of helicopter that has 74K polys.
I toggle subdevision level 2 in Nvil, Cinema 4d and MODO than looked at Task Manager.
Nvil consumes much more, 5 time more memory then Cinema 4D or Modo.
Check the screenshot...
-
Mason all that you say I know... But this topic is about perfomance not about topology...
And belive me I have reason to work with this detail in this subd level... And if you are very intrested why, tell me I 'll discribe you why...
-
You could model at half the resolution and have no loss in visible quality. I am only offering tips to speed up performance simply because Nvil may very well not get the performance boost you need until after you have finished the project. My working habit is to model cylinders with only 8 spans, and smooth it once and then delete all edge loops that are not needed for beveled edges.
That leaves a cylinder with 16 spans and smooths perfectly and is still sharp. I also use Ngons a lot, to keep topology light.
-
Mason, thanks for your tips but all that tips are just tips while Nvil remain very slow compare to the other applications... :(
-
Well, it has been stressed enough, but I was curious so I, too, loaded the rotor model in different applications:
Maya: 1 sec
Blender: 5 sec
Silo: 10 sec
NVil: 3 min 25sec
Also the loop cut operation on this model in Nvil was slower than in Silo. In Silo it was instant and fluid. In Nvil it lagged a little.
-
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 :-\
(http://s27.postimg.org/8wade6vwj/NVil_1_0_2014_Mar_28_delux_vws_modified_jpg.jpg)
-
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/ (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 (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.
-
I do have to agree that the Streamline tool workflow has made Nvil the fastest workflow of any 3d App I have worked with.
I think we have some cool enough works by the community here for marketing material.
-
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 :-\
(http://s27.postimg.org/8wade6vwj/NVil_1_0_2014_Mar_28_delux_vws_modified_jpg.jpg)
Check this
http://www.digitalfossils.com/Download/NVil-Apr-15-14.rar
The combine and obj export speed should be faster if the scene is heavy with a lot of objects.
-
Export 6 minutes, 8 minutes import, obj format
http://yadi.sk/d/C_iStkCrMpqHo link to the file
http://yadi.sk/d/Ojgqo-wAMpqX5 settings
-
Hi Darcvizer,
I exported your file as .obj, it exported in 6 seconds.
------------------------------
I missed hidden objects, so ignore.
-
Hi, very strange, I have cpu AMD FX 9590, 32 GB ram memory.
There's a scene there are two hidden mesh of 3d cout, they pay after a hard
(http://cdn.joxi.ru/uploads/prod/2014/04/20/589/525/f1c53cef11217201596b89317c38841c69267898.png)
-
There's a scene there are two hidden mesh of 3d cout,
Sorry. I missed the hidden objects.
With hidden object shown, it takes 1 min 25 seconds on my setup.
Majority of the time is spent combining(merge meshes) before export.
IStonia, why do you combine(merge mesh) all objects before .obj export?. It takes far too long, and why is it needed?. If user wants objects combined, let them do that themselves.
-
Isn't it merging based on what your OBJ export settings are, and limitations of the OBJ format?
-
Nvil merges all mesh for export to .obj by defualt, you cannot currently change that, into a single mesh in memory. The option (to divide) for export are to "Regroup polygons by meshes", which then adds face group information into the .obj file.
In the .obj file, exported from Nvil, there is only ever one object/vertex group.
The .obj format is not limited to that. All .obj exporters I have/do use, export as objects/vertex groups, not face groups.
Here is simple example.
2 box primitives exported to .obj from Wings.(option to export normals/smooth groups enabled)
You will see that each box(object) is divided into its own vertex group, followed by normals/smooth groups. On very large files with many objects, it means that the exporter can convert one object at a time and write it to an open file, close it when finished. It can save a lot of memory on export with multiple high polycount models.
# Exported from Wings 3D 1.5.2
mtllib wings_box.mtl
o Cube2
#8 vertices, 6 faces
v 1.00000000 -1.00000000 -1.00000000
v 1.00000000 -1.00000000 1.00000000
v 1.00000000 1.00000000 -1.00000000
v 1.00000000 1.00000000 1.00000000
v 3.00000000 -1.00000000 -1.00000000
v 3.00000000 -1.00000000 1.00000000
v 3.00000000 1.00000000 -1.00000000
v 3.00000000 1.00000000 1.00000000
vn -0.57735027 -0.57735027 -0.57735027
vn -0.57735027 -0.57735027 0.57735027
vn -0.57735027 0.57735027 -0.57735027
vn -0.57735027 0.57735027 0.57735027
vn 0.57735027 -0.57735027 -0.57735027
vn 0.57735027 -0.57735027 0.57735027
vn 0.57735027 0.57735027 -0.57735027
vn 0.57735027 0.57735027 0.57735027
g Cube2_default
usemtl default
s 1
f 1//1 5//5 6//6 2//2
f 2//2 4//4 3//3 1//1
f 2//2 6//6 8//8 4//4
f 3//3 7//7 5//5 1//1
f 4//4 8//8 7//7 3//3
f 5//5 7//7 8//8 6//6
o Cube1
#8 vertices, 6 faces
v -3.00000000 -1.00000000 -1.00000000
v -3.00000000 -1.00000000 1.00000000
v -3.00000000 1.00000000 -1.00000000
v -3.00000000 1.00000000 1.00000000
v -1.00000000 -1.00000000 -1.00000000
v -1.00000000 -1.00000000 1.00000000
v -1.00000000 1.00000000 -1.00000000
v -1.00000000 1.00000000 1.00000000
vn -0.57735027 -0.57735027 -0.57735027
vn -0.57735027 -0.57735027 0.57735027
vn -0.57735027 0.57735027 -0.57735027
vn -0.57735027 0.57735027 0.57735027
vn 0.57735027 -0.57735027 -0.57735027
vn 0.57735027 -0.57735027 0.57735027
vn 0.57735027 0.57735027 -0.57735027
vn 0.57735027 0.57735027 0.57735027
g Cube1_default
usemtl default
s 1
f 9//9 13//13 14//14 10//10
f 10//10 12//12 11//11 9//9
f 10//10 14//14 16//16 12//12
f 11//11 15//15 13//13 9//9
f 12//12 16//16 15//15 11//11
f 13//13 15//15 16//16 14//14
This is 2 box exported from Nvil, with option "Regroup polygons by meshes"
You will see one object/vertex group. The regrouped polygons are groups in the "Face list"
With that method, all mesh are merged in memory, then face info sorted in memory. On multiple large polycount model, that increases memory usage dramatically.
# Vertices: 16
# Faces: 24
# Materials: 1
o Object_Combined
mtllib nvil_box.mtl
# vertex list
v -1.470325 -0.5 0.5
v -1.470325 -0.5 -0.5
v -0.470326 -0.5 0.5
v -0.470326 -0.5 -0.5
v -1.470325 0.5 0.5
v -1.470325 0.5 -0.5
v -0.470326 0.5 0.5
v -0.470326 0.5 -0.5
v -0.10215 -0.5 0.5
v -0.10215 -0.5 -0.5
v 0.89785 -0.5 0.5
v 0.89785 -0.5 -0.5
v -0.10215 0.5 0.5
v -0.10215 0.5 -0.5
v 0.89785 0.5 0.5
v 0.89785 0.5 -0.5
# vertex normals
vn 0 0 1
vn -1 0 0
vn 0 -1 0
vn 0 0 -1
vn -1 0 0
vn 0 -1 0
vn 0 0 1
vn 1 0 0
vn 0 -1 0
vn 0 0 -1
vn 1 0 0
vn 0 -1 0
vn 0 0 1
vn -1 0 0
vn 0 1 0
vn 0 0 -1
vn -1 0 0
vn 0 1 0
vn 0 0 1
vn 0 1 0
vn 1 0 0
vn 0 0 -1
vn 1 0 0
vn 0 1 0
vn 0 0 1
vn -1 0 0
vn 0 -1 0
vn 0 0 -1
vn -1 0 0
vn 0 -1 0
vn 0 0 1
vn 1 0 0
vn 0 -1 0
vn 0 0 -1
vn 1 0 0
vn 0 -1 0
vn 0 0 1
vn -1 0 0
vn 0 1 0
vn 0 0 -1
vn -1 0 0
vn 0 1 0
vn 0 0 1
vn 0 1 0
vn 1 0 0
vn 0 0 -1
vn 1 0 0
vn 0 1 0
# face list
usemtl Mtrl_01
g Object_Box
s 2
f 1//3 2//6 4//12 3//9
s 4
f 5//15 7//20 8//24 6//18
s 8
f 1//1 3//7 7//19 5//13
s 16
f 2//4 6//16 8//22 4//10
s 32
f 1//2 5//14 6//17 2//5
s 64
f 3//8 4//11 8//23 7//21
g Object_Box_01
s 2
f 9//27 10//30 12//36 11//33
s 4
f 13//39 15//44 16//48 14//42
s 8
f 9//25 11//31 15//43 13//37
s 16
f 10//28 14//40 16//46 12//34
s 32
f 9//26 13//38 14//41 10//29
s 64
f 11//32 12//35 16//47 15//45
# End of file
------------------------------
Just for clarity.
Up until recently, I was not sure exactly what Nvil was doing on export to .obj, well apart from copying everything into memory before export. The merging of all mesh was a guess. However, after IStonia posted the debug versions to >this thread< (http://voidworld.cmcproductions.co.uk/index.php/topic,2323.15.html) for testing, it does show the merge mesh being used for .obj export.
-
Try this. It should be a lot faster on obj export.
http://www.digitalfossils.com/Download/NVil-Apr-16-14.rar
steve, on obj export, objects are duplicated then combine into one object. The data will be further modify for exporting. The duplication will consume memory. When combine, it does not merge meshes, so it consumes little memory and takes little time. The problem I found is I used a bad algorithm on polygon sorting.
-
Try this. The obj import speed is improved in case of separating into objects.
http://www.digitalfossils.com/Download/NVil-Apr-17-14.rar
Darcvizer, please let me know the test result.
-
Works very fast, 7 seconds export, import 32 seconds.For me it is very good news, thanks.
You're going to accelerate the work of the viewport?
-
steve, on obj export, objects are duplicated then combine into one object. The data will be further modify for exporting. The duplication will consume memory. When combine, it does not merge meshes, so it consumes little memory and takes little time. The problem I found is I used a bad algorithm on polygon sorting.
Which ever way you look at it, the .obj exporter, by default, merges mesh.
So is it the same issue with the Nvil "Combine" and "Combine(merge mesh) tools, a bad algorithm, that makes Nvil take far too long to merge large polycount mesh? It can take several minute to merge large polycount mesh, but (With you fixing the .obj exporter/importer) only several seconds to export/import via .obj, which does the same.
-
Yes, when writing into file, they are merged into one mesh.
The obj export shares the same function with object Combine, but not the object Combine(Merge Meshes).
The object/mesh Split still has performance problem. The same to polygon Split/Duplicate functions when all polygons are selected. I am currently fixing these and almost finish.
-
try this
http://www.digitalfossils.com/Download/NVil-Apr-19-14.rar
Also the Boolean performance is improved.
-
Once they started talking for boolean, then the video shows that in some cases it does not work, and it would be good to make it work on a mesh with holes
https://www.youtube.com/watch?v=MwzpYjap3DI&feature=youtu.be
http://yadi.sk/d/C_iStkCrMpqHo - file
extrude works well
-
Yes, when writing into file, they are merged into one mesh.
So I will ask yet again. Why do you merge all objects when exporting to .obj?
-
Seems you misunderstand. On the object side, there maybe multiple meshes, on the file side one obj file only holds a mesh. So when writing, data are read from meshes and written into file which is one mesh. That's why I called it merge. It is not merging into one mesh before write to file.
-
Seems you misunderstand.
No. It appears you do not understand.
On the object side, there maybe multiple meshes,
Yes, each object can be a single mesh, or have multiple mesh.
on the file side one obj file only holds a mesh.
It looks like you do not understand the .obj format, and how it can have multiple objects.
So when writing, data are read from meshes and written into file which is one mesh. That's why I called it merge. It is not merging into one mesh before write to file.
The result is the merging of all mesh into one object within the .obj file, That is what I am asking. Why do you merge all mesh.
.obj file can contain multiple objects, they are flagged either by "o"(object) or by "g" group, which are placed into the vertex list.
You place all vertex into one group, which equals one object/mesh, which is incorrect. Polygon groups can be placed in the face groups.
What you do is ignore the fact there are multiple objects in a scene, then give an option (in the .obj exporter) to divide the mesh into polygon groups (one polygon group per mesh). That of course conflicts with a multiple object scene with polygon groups set.
---------------------------------------------------------------
Here again is the .obj file from Wings. It contains 2 box(2 objects). I have added comment (original is in post above)
# Exported from Wings 3D 1.5.2
mtllib wings_box.mtl
o Cube2 << "o" = defining object (I have seen other .obj exporters use "g" for vertex group to define an object)
#8 vertices, 6 faces ---------------------------------
v 1.00000000 -1.00000000 -1.00000000 vertex list for box "Cube2"
v 1.00000000 -1.00000000 1.00000000
v 1.00000000 1.00000000 -1.00000000
v 1.00000000 1.00000000 1.00000000
v 3.00000000 -1.00000000 -1.00000000
v 3.00000000 -1.00000000 1.00000000
v 3.00000000 1.00000000 -1.00000000
v 3.00000000 1.00000000 1.00000000
vn -0.57735027 -0.57735027 -0.57735027 Vertex normal list for "Cube2"
vn -0.57735027 -0.57735027 0.57735027
vn -0.57735027 0.57735027 -0.57735027
vn -0.57735027 0.57735027 0.57735027
vn 0.57735027 -0.57735027 -0.57735027
vn 0.57735027 -0.57735027 0.57735027
vn 0.57735027 0.57735027 -0.57735027
vn 0.57735027 0.57735027 0.57735027
g Cube2_default <<< "g" = defining polygon group
usemtl default
s 1 <<< "s" = defining smooth group
f 1//1 5//5 6//6 2//2 -------------------
f 2//2 4//4 3//3 1//1 Face list for "Cube2"
f 2//2 6//6 8//8 4//4
f 3//3 7//7 5//5 1//1
f 4//4 8//8 7//7 3//3
f 5//5 7//7 8//8 6//6
o Cube1 <<<"o" defining next object in .obj file = "Cube1"
#8 vertices, 6 faces Repeat as above.
v -3.00000000 -1.00000000 -1.00000000
v -3.00000000 -1.00000000 1.00000000
v -3.00000000 1.00000000 -1.00000000
v -3.00000000 1.00000000 1.00000000
v -1.00000000 -1.00000000 -1.00000000
v -1.00000000 -1.00000000 1.00000000
v -1.00000000 1.00000000 -1.00000000
v -1.00000000 1.00000000 1.00000000
vn -0.57735027 -0.57735027 -0.57735027
vn -0.57735027 -0.57735027 0.57735027
vn -0.57735027 0.57735027 -0.57735027
vn -0.57735027 0.57735027 0.57735027
vn 0.57735027 -0.57735027 -0.57735027
vn 0.57735027 -0.57735027 0.57735027
vn 0.57735027 0.57735027 -0.57735027
vn 0.57735027 0.57735027 0.57735027
g Cube1_default
usemtl default
s 1
f 9//9 13//13 14//14 10//10
f 10//10 12//12 11//11 9//9
f 10//10 14//14 16//16 12//12
f 11//11 15//15 13//13 9//9
f 12//12 16//16 15//15 11//11
f 13//13 15//15 16//16 14//14
---------------------------------------------------
Out of curiosity, I decided to install Silo and check its .obj exporter. That also exports objects as being defined as "o" in the vertex list.
So there is no other .obj exporter that I can find that merges all objects into one mesh as Nvil does.
-
Ah, it is my misunderstanding. I always thought one object file can only contain one object and never doubt it. Well, I have to rewrite obj import/exporter.
-
The obj import/exporter is redone. See if it works correctly.
http://www.digitalfossils.com/Download/NVil-Apr-20-14.rar
-
Hi IStonia,
I did not think you would be re-doing the .obj importer/exporter yet.
On very quick checks, I can see a couple of problems up to now.
The face lists become incorrect.
The default polygon groups should they be named.(I have not checked yet as to what the .obj export options do)
Quick example:-
Simple scene with 3 box. .obj export default settings.
Comments added.
# Exported from NVil (1.0)
mtllib 3_box.mtl
o Object_Box
# Vertices: 8
# Faces: 12
# Materials: 1
# vertex list
v -1.5 -0.5 1.5 #vertex list of "object_Box"
v -1.5 -0.5 0.5 # Vertex numbered 1 to 8
v -0.5 -0.5 1.5
v -0.5 -0.5 0.5
v -1.5 0.5 1.5
v -1.5 0.5 0.5
v -0.5 0.5 1.5
v -0.5 0.5 0.5
# face list
usemtl Mtrl_01
g # Group name?
s 2
f 1 2 4 3 #face list using vertex numbers from "object_box", correct
s 4
f 5 7 8 6
s 8
f 1 3 7 5
s 16
f 2 6 8 4
s 32
f 1 5 6 2
s 64
f 3 4 8 7
o Object_Box_01
# Vertices: 8
# Faces: 12
# Materials: 1
# vertex list
v 0.5 -0.5 1.5 #vertex list of "object_Box?_01"
v 0.5 -0.5 0.5 #Vertex numbered 9 to 16
v 1.5 -0.5 1.5
v 1.5 -0.5 0.5
v 0.5 0.5 1.5
v 0.5 0.5 0.5
v 1.5 0.5 1.5
v 1.5 0.5 0.5
# face list
usemtl Mtrl_01
g #Group Name?
s 2
f 9 10 12 11 #Face list using vertex numbers from "object_Box_01", correct
s 4
f 13 15 16 14
s 8
f 9 11 15 13
s 16
f 10 14 16 12
s 32
f 9 13 14 10
s 64
f 11 12 16 15
o Object_Box_02
# Vertices: 8
# Faces: 12
# Materials: 1
# vertex list
v 0.5 -0.5 -0.5 #vertex list of "object_Box_02"
v 0.5 -0.5 -1.5 #Vertex numbered 17 to 24
v 1.5 -0.5 -0.5
v 1.5 -0.5 -1.5
v 0.5 0.5 -0.5
v 0.5 0.5 -1.5
v 1.5 0.5 -0.5
v 1.5 0.5 -1.5
# face list
usemtl Mtrl_01
g #Group name?
s 2
f 9 10 12 11 #Face list using vertex numbers from "object_Box_01", incorrect.
s 4
f 13 15 16 14
s 8
f 9 11 15 13
s 16
f 10 14 16 12
s 32
f 9 13 14 10
s 64
f 11 12 16 15
# End of file
In that simple example, when loading the .obj file, you just get overlapping box. But in a scene where you have various objects with different number of vertex, objects(saved as .obj) are corrupt due to incorrect face lists.
Screen_shot of 3 box with different number of vertex.
(http://i.imgur.com/pQGkZxt.jpg)
Saved as, then loaded as .obj. Objects corrupt.
(http://i.imgur.com/Q0I2MPG.jpg)
---------------------------------------------------
Just very quickly looked at the option in .obj export "Regroup polygons by meshes"
When used, it is placing all polygons from all mesh into the same named group.
Should that option still be there/needed?
-
Try this one
http://www.digitalfossils.com/Download/NVil-Apr-21-14.rar
-
Hi IStonia,
The face lists(vertex ref numbers) now appear to be numbered/ordered correctly. (I still need to check more for VN and VT)
The export option "Regroup polygons by meshes" is still incorrect. That is still placing all polygons into same named group. (for example. I have 3 box in scene "Object_box", "Object_box_01" and "object_box_02" each with one mesh. I export with option "Regroup polygons by meshes", the 3 object face lists are grouped with name "Box"). [to add]Looking through the naming of the mesh in scene, they are in fact all named "Box" in the example. I find that strange considering that objects cannot have the same name. I see similar mesh naming in earlier versions, but those names are changed in .obj file exported.
With default export settings(no regroup), any polygon groups set, appear to be exported OK. But I will need to check that with other .obj importers (that support polygon groups) as well as Nvil. (I will probably check the importer from 3D coat, due to link).
Materials(colors) appear to be exporting/importing OK
I still need to make checks on hard_edge and smooth group export/import.
-------------------------------
Checking more with polygon groups.
I looked at simple scene with 2 Box. Each box had one polygon in a separate group. Then one polygon from each object placed in a 3rd group.
The export appears to be OK, but import of polygon groups that span multiple objects is splitting/re-naming those groups.
In the simple example. It looks like on import(default settings), polygon groups with same name on different objects, instead of them being loaded as one group, the second group is re-named and a new group created.
I can post example files/pics to better explain the issue if needed.
---------------------------------
Off topic.
With taking note of objects/mesh and groups when checking, I find that scene management is a complete nightmare. Having to have 3 different windows open to keep track of objects/mesh and groups is not something I would want to do if I had projects that needed scene management.(which they would if it was work/project for someone other than myself).
Hopefully, some time in the future, you could look at better organization?.
//
-
Try this one
http://www.digitalfossils.com/Download/NVil-Apr-22-14.rar
-
Hi IStonia,
The set groups now appear to be OK. (groups spanning multiple objects are saved/imported correctly)
The exported groups via "Regroup Polygons by Meshes" is still repeat naming as I mentioned above. But considering Nvil and other applications I have checked can deal with that on import, I do not think an issue.
I need to check normals/texture lists. So will post back finding later.
-------------------------------------------------
There is a slight issue if .obj files are imported/merged when the .mtl file for that .obj file is empty/missing. The objects appear to be wireframe until a material is applied to them.
If the .mtl file is empty/ missing, should a default material not be automatically applied?
What I would normally see, is the material names from the .obj file are loaded, but if the .mtl file is missing, those materials are filled/ applied with default color.
----------------------------------
UV's and normals appear to be OK up to now.
-
Try this
http://www.digitalfossils.com/Download/NVil-Apr-23-14.rar
-
Hi IStonia,
A default material is now added if .mtl file missing. So OK.
Have checked Vertex normals, and those export/import correctly.
One thing at the moment. Which is memory usage with .obj import.
As a simple example. I have a scene in .vws format that I load. After it is loaded, total memory usage by Nvil is approx 556 MB. I save that scene as .obj. Restart Nvil, and load that scene from the .obj file. Memory usage by Nvil is then approx 1.15 GB.
Why is memory usage so much more (when importing via .obj format) for the exact same scene?
Loading that same scene from .dae, that as similar memory usage as the .vws file.(approx 564 mb)
-
How many objects in that scene?
-
72 objects
72 mesh
148,916 polygons.
-
Try this
http://www.digitalfossils.com/Download/NVil-Apr-24-14.rar
Also recheck vt and vn. They are affected.
-
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