|
|||||||
![]() |
|
|
Thread Tools |
|
|||
|
MESH OPTIMISER v 0.92 -UPDATED
WARNING: I'm redoing the script with Abidos so there will not be updates in a near future i'm sorry though we expect to come up with a stable solution. Thanks to the community for the interest in the script! We are trying to pay back with our hard work ![]() I'd like to say thanks to FourMadMen for helping me with starting to use Blender, Finanzamt for having the first reasonable approach and Crouch for the holes detection and other constructive criticism. I've also had in the process some disagreements with Abidos but now we are working together on the same project, to create something really useful for the community. The next upload of the script will have a version made by both of us. Demo: Before: ![]() After: ![]() The aim of the script is to provide a inverse operation to the subdivide method in Blender. Basically, the script reduces the poly & vert & edge count NEVER changing the shape of the object UNLIKE DECIMATOR OR OTHER POLY-REDUCERS. For instance, if you have a face that is nothing more than a plane but it is composed of several faces, it will remove all those faces and you'll have only one plane. Imagine a cube. Now subdivide it the amount of times you wish. Now run the script. You'll get the original cube with only 8 vertices just like it was prior to the subdivision. The script started after my cry for help and in this thread you'll see the discussion: http://blenderartists.org/forum/showthread.php?t=140970 It has now reached a phase that can be considered as usable. This is a beta version so please save your work before using the script, then select the object and run the script. The script doesn't work with vertices that have no adjacent faces yet but as soon as I have time, it will be easy to add. Sometimes the script leaves more verts than it should, I still have no clue as it rarely happens and seems to be random. The script was built with speed in mind, in fact, with this scene and an old AMD Opteron it only took one minute and a half to optimise the mesh and I was in debug mode (you will see the mesh being optimised in real-time before your eyes) wich makes it a lot slower. Please test it and give back feedback so I can improve it! Enough talking: http://www.mediafire.com/?dwcmijv9kzy Instructions: 1-Before running the script save the scene 2-Select the mesh you wish to optimise 3-Run the script Last edited by AlbertoEAF; 19-Apr-09 at 09:23. |
|||
|
#1
|
|||
|
|
|
|||
|
Tested it, but nothing seems to happen. I tried it with a subdivided Suzanne (1 level of SubSurf and applied the modifier), and then I used only a cube, added Subsurf, applied it, and run the script, but it remains the same.
It gaves me this message: Code:
............................................
Video: Surface Sketching script (timelapse demo) Video: Arrays Sketching script demo. Video: Three Levels UI concept ... ( UPDATE 16-Mar-09 ) |
|||
|
#2
|
|
||||
|
hum
tried it with a mesh ahving around 600 vertices but it has reduced qty vertex by only 3 vertices ? what is the % of reduction youc an expect from tnis Script ? ok tried another one and it did reduced byt 50 % the vertex count ! \but you should at the beginning say that you need to select all vertices in edit mode before applying the script i think ? Thanks Last edited by RickyBlender; 16-Apr-09 at 18:50. |
||||
|
#3
|
|
||||
|
Great idea. I could use this for when I get those verts leftover from lots of playing around with mesh.
I think people might be misunderstanding the idea of 'optimizing' the mesh. The purpose is to eliminate verts that are superfluous, correct? Maybe you could call it an 'intelligent merge' or something. good work - thanks for the post and script. |
||||
|
#4
|
|
|||
|
Yes the script eliminates only the verts that do not change the shape of an object, just like teldredge said.
Eclectiel: I'm talking about using the script after the subdivision, not after subsurf since with subsurf you get a mesh in which all the verts are required to mantain it's shape so none is removed. RickyBlender: you only need to have the object selected in object mode or have the object in edit mode, the script does the rest. The percentage of reduction to be expected from the script depends on the mesh. This happens because the script is not a normal mesh optimiser, instead it reduces the poly-count ALWAYS mantaining the shape of the object. That's what it is for: after doing a lot of knife cuts, subdivision, etc. on an object and you want to reduce the number of faces without changing it's shape you use the script so that you don't have to merge verts by hand which can take hours even for the simplest scenarios. Please see the beginning of the post, I've uploaded some pics to make it easier to understand. Last edited by AlbertoEAF; 16-Apr-09 at 20:29. |
|||
|
#5
|
|
||||
|
Oh my GOSH! I have been looking for a script like this for months! You really should broadcast it on gaming sites fort those who make higher-poly models but want to lower the count for the game without totally redoing the mesh. I have put this script in a special folder where it will be safe forever. Thanks A BUNCH! - YoungApprentice
![]() ![]() ![]()
............................................
My current game WIP- Platfall TO ALL YOU PHYSICS DUDES OUT THERE- Check this game out! There is a physics bug that I can't seem to figure out! ![]() ============================================= "I have no data yet. It is a capital mistake to theorize before one has data. Insensibly one begins to twist facts to suit theories, instead of theories to suit facts."- Sir Arthur Conan Doyle (Sherlock Holmes) |
||||
|
#6
|
|
|||
|
Thanks a lot YoungApprentice
![]() but be aware that this is still a beta version and sometimes you will encounter some overlapping faces like in the right corner of the mesh in the floor where the color is a little redish. I still haven't had time to fix this but will definitely do it when I find some spare time. Thanks once more |
|||
|
#7
|
|
||||
|
nice tool !
I've noticed some strange behaviour : . for big mesh (36225verts) I have to select all verts in editmode else : it won't change anything. it sometimes fire this error : Code:
subscribed thread, really cool so far :-) |
||||
|
#8
|
|
|||
|
Thanks for the input littleneo.
I don't know why you have to select the vertices in editmode since I don't use selected verts in the script. I hope I've taken care of the KeyError bug: remove the me.remDoubles(0.01) line at the beginning of main() I've tested what you've said, and I know what is causing it. The script skips optimizing if there are no edge_verts. Bug fixed Thanks, I'll upload the script again in the weekend Last edited by AlbertoEAF; 16-Apr-09 at 22:58. |
|||
|
#9
|
|
||||
|
ok i think i get the idea here of the function it does
but you should still put a note at the beginning of the program to tell that you only have to select the object in object or edit mode it's only fair i guess! and it's great to clean up a mesh i would suggest a more appropriate name like Mesh minimiser / cleaner or may be the nesh vacum cleaner ! LOL very good work this was needed for a long time can't wait to get the latest version Thanks |
||||
|
#10
|
|
||||
|
FAB SRIPT
but i can't get it to work on my car some reason, it comes up with "python error, check consal" then it highlights in red: Code:
ITS GREAT!
............................................
windows 7 and xp using a dual boot so dont be supprised if im always switching beetween them. www.ionee.org tutorials here!!! (videos!) all new tutorials here!!! (not video) current project/s: parkour pro game thread here ............. ...............
|
||||
|
#11
|
|
||||
|
This script works fine on some simple meshes (even with many verts) but it as soon as the mesh is more "special" in terms of verts location, problems appear in the resulting mesh.
I've seen a lot of my ideas incorporated in the script. About 80% of routines used in the script are developed be me from scratch (working to help Alberto under "Remove or merge vertices in python" thread) and script does not do the task any better that my published script under the "Remove or merge vertices in python" thread (see my posting of 05.04.2009 and 06.04.2009) - the same problems remain as there is no routine to deal with then in the so caled "NEW" script, heh..... One exeption in my script of 05.04.2008 - CheckForHoles(ob,lst) routine was originated by Crouch (I improve it later again under the other thread). In current so caled "NEW" script NO credit is given to me for all that, hummm... This is simply not the way to work out open sorce code! So I will not comment how to avoid certain problems created by the script. I am also not going to comment what measures can be taken to optimise script performance.... Regards, Last edited by Abidos; 17-Apr-09 at 10:05. |
||||
|
#12
|
|
||||
|
ohh
well done then for the script then.
............................................
windows 7 and xp using a dual boot so dont be supprised if im always switching beetween them. www.ionee.org tutorials here!!! (videos!) all new tutorials here!!! (not video) current project/s: parkour pro game thread here ............. ...............
|
||||
|
#13
|
|
|||
|
man this script is amazing
i tested on a car im working on for the movies game, with 43760 faces and got it reduced to 37741 congrats alberto |
|||
|
#14
|
|
||||
|
Here is the script that I published about 10 days ago..... It does the same as the "NEW" script of Alberto!!! Funny, right???
To all others - yes, the script is useful as my "OLD" one.... but sometimes it causes problems and you will not know when and why... I'd be working on improving this since I have done this half way already! Here's link to a thread witn problems (published on 08.04.2009 in this forum). Regards, Last edited by Abidos; 17-Apr-09 at 11:52. Reason: edits |
||||
|
#15
|
|
|||
|
i know nothing about python, but looking at both scripts side by side i dont see any comparison. in the code.
maybe they both do the same thing but in different ways. so i cant see how you can claim that he has stolen your work. @ alberto i tested the script using a cube subdivided so it had nearly 100,000 verts, it reduced it down to 717 but if you look at the pic below is there any way to make it more cleaner, surely it would have cleaned it back to 8 vertices
Last edited by stvndysn; 17-Apr-09 at 11:20. |
|||
|
#16
|
|
||||
|
You're right, stvndysn!!! I was looking something else...
the "NEW" script leaves the resulting mesh with the same problems as my "old" one... Here's a link with its problems. I have solved some of them but I wish I had some support at least in terms of ideas, algorythms for how to cope with the issues...... And stvndysn you have reached a mesh which is a classical example of overlapped faces. My script clears them up while currently proposed script doesnt...
|
||||
|
#17
|
|
||||
|
OK, here are some tests that I made......
Using one and the same testing object with a "bump" and 2 square holes on the top Body face: ![]() verts = 138 edges = 286 faces = 148 I tested performance of the two scripts. RESULTS: ============================ "New" Alberto's script result: ![]() verts = 25 edges = 59 faces = 34 Processing time = 150 milliseconds ================ My "Old" script (06.APR.2009) result: ![]() verts = 24 edges = 50 faces = 26 Processing time = 67 milliseconds ================ Tests made on Blender 2.46, Python 2.5, Windows XP, 2.2 GHz Dual Core machine with 2 GB RAM. It seems that my script of 06.APR.2009 gets better results. And have you noticed the overlapping face at top-left on Alberto's script result?? Both produce several faces with area = 0 (hiddeb triangles) but at least mine does NOT produce overlapping faces unless the mesh is really a very complicated one and/or it had problems (overlapped faces, hidden face, etc.) before running my script. Both scripts produce a non-optimal mesh as many tris appear on the top Body face of the results and these tris are NOT joinable by the integrated BLENDER function "Join triangles". THat's why I think a more complex re-work of the mesh is need before supplying it to the user back in BLENDER. I call my script "OLD" cause I have a new version which copes with some of the problems listed here... I'd be happy to improve it ro cope with ALL mesh problems that may occur on an unknown mesh. Regards, Last edited by Abidos; 17-Apr-09 at 13:10. |
||||
|
#18
|
|
|||
|
@stvdysn: thanks for making some justice - about the overlapping that occured in your example it's caused because the function from Abidos that gives the angle between 2 vecs returning improper values.
@abidos: You again displayed an arrogant attitude so now I will tell the other people the truth. The truth is that i stole nothing from your script except for the function that returns the angle between two vectors - - I will give you credit for this in the next version of the script. And if you want to claim that the rest of the code is yours, it truly isn't; in fact that function is only 5% of my code. Also I had made some comments on your work when you came to the thread and like if you owned the place you replied in an arrogant way, so at that time I left the thread and made my own new logic - the script has nothing to do with yours - nothing in code neither logic. Also when I last tested meshes my script ran them with less errors than yours (even your meshes) and my script was done on 9 April I just hadn't uploaded it since I was getting rid of some bugs-and of course I'm still not done. Also I considered it a NEW script because the idea that started the thread was mine and at the time your script didn't produce consistent output. To see what I'm saying try the link in this post to the .blend file and test the script in the objects. First part of my script - reading the mesh: The way your script works requires at each vert looking for adjacent verts while mine has a completely new logic of reading the mesh. In fact my old method (similar to your script that appeared after) takes in a mesh with 24578 verts and 24576 faces: 910.835413933 seconds to read the adjacent verts ( 15.18 minutes ) + 585.035928965 seconds to read the adjacent faces ( 9.75 minutes ) +time to read the adjacent edges which accounts for 1495.87 seconds or 24.93 minutes while my new redone method takes: 0.16971206665 seconds to read the adjacent verts + 0.127423048019 seconds to read the adjacent faces +time to read the adjacent edges (this will eliminated in a future version) which accounts for 0.2971351147 seconds So it is 5034.3 times faster! And this discrepance only increases with vert-count because the older method increases time exponentially and the new one only increases runtime linearly (I found a way to read the mesh only once by each stage - and it's possible that they can be merged together reducing runtime even further). So, with my new method instead of taking minutes to scan a mesh it takes few seconds which is imperative since it doesn't make sense to have a script that takes more time reading the mesh than working. Main logic: I reimplemented the logic of the script using only connected_elements data structures to reduce the mesh which is fast like hell. But like I said this is still a beta version, so, it still has errors. Basically my script has nothing to do with yours, I did it when I was absent from the forums and being much faster I uploaded it. If you don't believe me see the code of the scripts side by side; this is the last work that I had seen from Abidos: http://s2.orbitfiles.com/index.php?l...21d842&force=1 - my script and his have got nothing to do with each other. Now, if you are willing to come clean, and display a less arrogant attitude I would be willing to cooperate. Sorry for the negative post but I hate liars. Last edited by AlbertoEAF; 17-Apr-09 at 14:07. Reason: some things were left unsaid |
|||
|
#19
|
|
||||
|
Good job very useful.
|
||||
|
#20
|
![]() |
| Bookmarks |
| Thread Tools | |
|
|