DNM effiecency
- Neocon
- First Class Membership
- Posts: 3955
- Joined: Wed Oct 19, 2011 5:01 am
- Favorite Aircraft: Baron 58
- Location: Tennessee
- OS: Win 10
- Has thanked: 1770 times
- Been thanked: 1810 times
- Contact:
DNM effiecency
I'll start with the duplicate PCK entries. An example would be the wheels. Let's say you have a plane with three wheels that are identical. There is no reason to have duplicate surf file PCK entries for each wheel. You can have a single PCK wheel.srf... shared among several entries in the parts tree, where you have SRF "wheel_main_l", SRF "wheel_main_r", , and SRF "wheel_nose"; and use the coordinate system to rotate them as needed. I don't know if that is possible in Blender or if Blender automatically makes a whole new PCK entry for each duplicated wheel. If you can share the same PCK entry for multiple SRF entries in the parts tree, that would save quite a bit on file size.
Next is the issue of overly-comlicated text. One of the biggest offenders I've seen is the letter "O". Not only are they overly complicated in the number of verticies, but it seems they are being turned out as a series of triangle faces. When I make a letter, I generally try to to use more than three or four faces. For example, with the letter "C" I might use only two or three faces, so for the letter "O" I would only use four faces. The letter "T" would only have two faces, although I've gotten away with only one face before. Triangluarized "O"s seem to reflect light oddly sometimes, on top of the file size issue. Each face takes up several lines of text in the .dnm file, and an "O" with 100 faces is going to take up a significant amount of space, which in turn increases the file size and reduces performance in YSF. If you can, it is probably better to simplify the letters, which can most likely be done without reducing the quality of the letters. I've noticed that the word "'Ohana" used on the 'Ohana planes takes up as many kb's of memory as the rest of the plane combined. Add on top of that it is used twice, so it has a duplicate PCK entry. Removing the duplicate and pointing both SRF entries in the parts tree alone reduced the file size of the 737 by 1/3. Simplifying the remaining text reduced it again, resulting in a final file size of half of its original size, which should improve frame rates and decrease lag online.
I've noticed a few .dnm files that have a bunch of SRF "nullxxx.srf" entries in their file trees. What is strange is that, A. they didn't have child SRF's attached, so they obviously had no purpose of existing in the first place, and B. they had coordinates placing them several kilometers from the center of the object. They were easy to clean up. My reason for mentioning them is that just cleaning up loose ends like those reduced the file size of the .dnm significantly (about 10-15%!), and only took a couple of minutes. Please clean up your work before releasing it. Silly things like that can make a big difference both in download size and performance in YSF.
Finally, I've noticed that in some models there will be a PCK entry where the surf file has a name like "mesh.001". Somehow, both YSF and DNMViewer seem to comprehend that "mesh.001" is a .srf file, even though it lacks the ".srf" in its name. This has a negative impact on people like me who modify planes by using dnmexp.pl and then importing them into gepolyx. Gepolyx will only import .srf files, and Windows reads them as "mesh.001" with no file type. I then have to rename it to "mesh.001.srf" so it will be recognized by gepoly. When I get ready to return it to the .dnm, I either have to change the name of the surf in the parts tree to have the ".srf" at the end, or I have to remove the ".srf" from the file name after I paste it in. It only takes an extra few seconds, so I live with it. What concerns me is that a future update to YSF may stop recognizing surf files without the ".srf" file type in its name in the PCK entry of the .dnm.
In conclusion, I hope those of you who make or modify models for YSF will take steps to make your files more efficient, which will result in a better experience for everyone using them.
- u2fly
- Senior Veteran
- Posts: 1485
- Joined: Fri Oct 02, 2015 9:27 am
- Favorite Aircraft: Antonov An-225 Mriya
- Location: Ukraine
- OS: Linux
- Has thanked: 1051 times
- Been thanked: 339 times
Re: DNM effiecency
Now i try collect all info about YS formats in one nice book, so will add this info too.
Here is PDF with table of content
U.S. Senator John McCain wrote:“Spending #NewYearsEve w/ brave #Ukrainian Marines at a forward combat outpost
- we stand w/ them in their fight against #Putin's aggression”
pic.twitter.com/vkz0gdozVV [archived]
(31 DEC 2016)
- Dragon_Mech
- Veteran
- Posts: 571
- Joined: Wed Jul 15, 2015 12:18 pm
- Favorite Aircraft: F-14, F-15D&E, SR-71, King Air 200, B737
- Location: Mansfield, Mo. USA
- OS: Windows 7 Ultimate
- Has thanked: 94 times
- Been thanked: 127 times
Re: DNM effiecency
-
- Senior Veteran
- Posts: 1851
- Joined: Tue Feb 07, 2012 10:00 am
- Favorite Aircraft: .
- OS: windoze 10 64-bit
- Has thanked: 617 times
- Been thanked: 619 times
Re: DNM effiecency
2) Decimate modifier in Blender, or you can set DefRes to a lower value before converting the text into a mesh. This reduces the vertex count significantly for text. You can also switch out the default font for another less complex font. I notice that many mods made by less experienced people have this issue.
3) Completely dependant on modder competence.
4) See my "Some tips" thread.
Also this causes D3D to mess up and crash on less capable computers. This issue is endemic in HQ mods, even in decaff's aircraft.
- Flake
- VFA-49
- Posts: 4375
- Joined: Thu Feb 10, 2011 8:47 pm
- Favorite Aircraft: Boeing F/A-18A
- Location: Australia
- OS: Windows 10 (x64)
- Has thanked: 861 times
- Been thanked: 1279 times
- Contact:
Re: DNM effiecency
Regarding this you do save a few lines in the SRF file, but YSF Does have to recalulate the convexnised poly.Patrick31337 wrote:Next is the issue of overly-comlicated text. One of the biggest offenders I've seen is the letter "O". Not only are they overly complicated in the number of verticies, but it seems they are being turned out as a series of triangle faces. When I make a letter, I generally try to to use more than three or four faces. For example, with the letter "C" I might use only two or three faces, so for the letter "O" I would only use four faces.
4-5 vertecies per poly is about the max you can get away with before it starts to use very slow calculation methods. In fact this is what causes the confusion and peep hole effects between DX and GL as they render differently.
3 vertex polys can be instantly transformed to the OpenGL / DirectX pipeline. (The 3d engines of graphics cards work in triangles only.
That said, I am a huge fan of using 4 vertex polys (Quadrilaterals) as they make repainting / modding, especially in GePolyX much easier.
The solution is what NR said: Simply your models. The letter O doesn't need 500 faces in it.
I use a tolerance of ~5-20 degrees for corner smoothness myself, depending on the importance of the part.
For example: 90 degree smoothness for a wheel results in square tyres and is not acceptable. I say 10 degrees is acceptable though. (36 sub-divisions). The smoother you try and make a part or decal, the more polys you need. The trick is not necessarily to sacrifice quality, but to re-image what you plan to do to work within the constraints.
- decaff_42
- Staff
- Posts: 3838
- Joined: Sat Oct 29, 2011 7:23 pm
- Favorite Aircraft: SR-71 Blackbird
- Location: Eastern United States
- OS: Mac OSX
- Has thanked: 844 times
- Been thanked: 1727 times
- Contact:
Re: DNM effiecency
I'd like to address some things that have been brought up and add my own penny to the conversation.
(1) Text in YSFlight
As Nightraven has mentioned, reducing the vertex count of text before conversion to a mesh in Blender is a MUST. You can easily see the impact with some quick data from Blender
As you can see, compared to the default DefRes = 12, we can save 80% in faces by going thru and doing some quad-making (ctrl -> j ) and cleaning up the mess that makes, you can save upwards of 45% on the baseline text of a particular DefRes. Since this is ONLY for the default Text word, you can expect higher savings with words that have more curved portions, perhaps as much as 90-95% when you are done working on it. In terms of just faces, the DefRes=4 was 76% less than the default, and the DefRes = 3 was 80% less. As you can see below the detail difference is not extreme between the last two, but perhaps the best balance between detail and performance is the DefRes = 4.
If there are lots of duplicate features there could be HUGE file size savings.
Here's some data:
For a given vertex, you save one line in the DNM file straight out. This will save you between 24 and 27 characters, each takes up x number of bytes a piece.
Code: Select all
V -0.0569 -0.0111 -0.1021 R
Code: Select all
F
C 210 186 148
N 0.0154 0.0342 0.1058 0.4774 0.0585 0.8767
V 4 42 68
E
If we look at the number of lines saved, it is really easy to see how this will add up.
DefRes12 = 839 Lines
DefRes4Quad = 358 Lines
DefRes4Decaff = 283 Lines
DefRes3Decaff = 241 Lines
In terms of lines and number of characters, there was a 70% savings in the DefRes3Decaff vs the DefRes12 default text.
(2) Duplicate SRFs
As Nightraven mentioned, the Alt-D duplication does reduce the vertex count significantly as the linked objects will have the same SRF name in the DNM file, but refer to a common mesh. This has the added benefit in Blender of creating a link between the two so if you edit one (paint, modify, etc) you edit them all. This is how I was able to make the nozzle for the F-20 work well, as the animations were carried over too! In the DNM file, all the 12 petals refer to a single mesh listed in the SRF section of the DNM file. You can see this in the CLA definition stage with FIL line under the SRF line.
Code: Select all
SRF "petal_1_panel.029"
FIL Mesh.500
…
SRF "petal_1_panel.028"
FIL Mesh.500
(3) PCK Mesh.### Entries
I took a look thru the DNM of the F-20 that I exported from Blender, and every SRF in the SRF section was a mesh.###. As I mention above, these are assigned to SRFs in the CLA definition section of the Blender-generated DNM file that I have in front of me.
(4) Null SRFs
I am not sure where these are coming from, however when I did a search thru my F-20 DNM, I did not find any.
I shall do some experimentation to see if I can reduce the dnm size of the F-20 models I am working on by taking further advantage of the Alt-D duplication and report back on results when I have them.
EDIT: I am able to confirm that Alt-D duplicated objects can be animated differently. However, since they are duplicated, you loose the ability to clear object rotations via the Apply Scale/Rotation to Object Data feature (Ctrl->A-1)
If you have already duplicated without linking, you can go back and link them by selecting both objects and pressing Ctrl->L and select Mesh Data. I did this to the F-20C and got a 2% file-size savings. There is more simlarity in the F-20D, so I think That will save even more!
EDIT 2:
F-20D saved 20% on the DNM file size. Thanks to aggressive duplication in the cockpit, The D model is at 2.4mb where as the C model is at 2.2mb after the linking of duplicated objects. This is awesome news. I will have to re-work a few things with the models I have already painted, but this kind of savings are golden!
Visit my GitHub page for Python codes: https://github.com/decaff42?tab=repositories
YSFlight Addon Database - Find links to nearly every addon made for YSFlight!
Submit Addon To Database
- Neocon
- First Class Membership
- Posts: 3955
- Joined: Wed Oct 19, 2011 5:01 am
- Favorite Aircraft: Baron 58
- Location: Tennessee
- OS: Win 10
- Has thanked: 1770 times
- Been thanked: 1810 times
- Contact:
Re: DNM effiecency
-
- Senior Veteran
- Posts: 1851
- Joined: Tue Feb 07, 2012 10:00 am
- Favorite Aircraft: .
- OS: windoze 10 64-bit
- Has thanked: 617 times
- Been thanked: 619 times
Re: DNM effiecency
While this does not normally affect performance per se, it does, like I have said before, cause D3D YS to crash on less capable computers. So I would say renaming the mesh with the .srf extension is good practice.decaff_42 wrote:(3) PCK Mesh.### Entries
I took a look thru the DNM of the F-20 that I exported from Blender, and every SRF in the SRF section was a mesh.###. As I mention above, these are assigned to SRFs in the CLA definition section of the Blender-generated DNM file that I have in front of me.
- Neocon
- First Class Membership
- Posts: 3955
- Joined: Wed Oct 19, 2011 5:01 am
- Favorite Aircraft: Baron 58
- Location: Tennessee
- OS: Win 10
- Has thanked: 1770 times
- Been thanked: 1810 times
- Contact:
Re: DNM effiecency
- Flake
- VFA-49
- Posts: 4375
- Joined: Thu Feb 10, 2011 8:47 pm
- Favorite Aircraft: Boeing F/A-18A
- Location: Australia
- OS: Windows 10 (x64)
- Has thanked: 861 times
- Been thanked: 1279 times
- Contact:
Re: DNM effiecency
This one really is a matter of personal preference. Personally I like having full ARGB color palette but some addons don't even need it.Patrick31337 wrote:Something that can also reduce the file size by a small amount is converting the color codes from rgb to YS. Again, it is a small amount. 573 kb to 554 kb small.
back end wise, that does need to be converted back to hex to be used by DX and GL though (like, 1/1000th of a second?) but yeah, there's that. It's a bitwise operation though so it's very fast.
Also, regarding decaff's post...
Decaff has my seal of approval in regards to YSF knowledge - I'm the guy to speak to re: netcode and things. Decaff is the guy to speak to regarding most other things. Decaff, you are a tank. I love your work.
Who is online
Users browsing this forum: No registered users and 3 guests