Board index FlightGear Development

Can we use a faster 3d model format

FlightGear is opensource, so you can be the developer. In the need for help on anything? We are here to help you.
Forum rules
Core development is discussed on the official FlightGear-Devel development mailing list.

Bugs can be reported in the bug tracker.

Can we use a faster 3d model format

Postby MIG29pilot » Sun Aug 16, 2015 8:43 pm

Title should be fairly self-explanatory, but I will at least elaborate: The current format we use (ac) seems to slow down FG like pond of treacle. It might be something else of course, but lets treat the 3d model format as the scapegoat. Now then, is there any other format that we are free to use that is faster
User avatar
MIG29pilot
 
Posts: 1454
Joined: Tue May 19, 2015 4:03 pm
Location: 6 feet under Snow
Callsign: MIG29pilot
Version: 3.7nightly
OS: Windows 10

Re: Can we use a faster 3d model format

Postby legoboyvdlp » Sun Aug 16, 2015 8:51 pm

Just why do you blame it on .ac?
Plus if it is that its because your PC cannot handle detailed models
User avatar
legoboyvdlp
 
Posts: 7123
Joined: Sat Jul 26, 2014 1:28 am
Callsign: YV-LEGO
Version: 2018.3.1
OS: Windows 10 HP

Re: Can we use a faster 3d model format

Postby Buckaroo » Sun Aug 16, 2015 9:29 pm

.ac is just a model file format, simple and easy to parse. It will have little to do with Flightgear running like a pond of molasses. It would not be wise to treat it as a scapegoat for an ill-defined problem.

-Buck
Callsign: Buckaro(o)
Author: Lockheed 1049H Constellation, Grumman Goose, MD-81, Edgley Optica, Velocity XL RG, YASim Guide
User avatar
Buckaroo
 
Posts: 475
Joined: Fri Jan 18, 2008 6:45 am
Location: Bloomington IN USA
Callsign: Buckaro(o)
Version: 2.10
OS: Windows & Linux

Re: Can we use a faster 3d model format

Postby Richard » Sun Aug 16, 2015 10:18 pm

The model format only affects the model load times as whatever the format the model will end up in the scenegraph. LOD management and more use of multithreading are signifcant steps along the road to a better framerate.

I tested various models in the .ive format and the load was much improved; but it's still the same geometry.

If you want to try this then you can convert models into .ive using the osgconv and see for yourself.
Richard
 
Posts: 716
Joined: Sun Nov 02, 2014 10:17 pm
Version: Git
OS: Win10

Re: Can we use a faster 3d model format

Postby Buckaroo » Sun Aug 16, 2015 11:00 pm

A native OSG binary format like .ive will undoubtedly load faster, but it's not going to be the cure-all solution for a setup that runs like "treacle".

I am curious at the difference in load-times, if anyone happens to have data. I might convert some of my efforts.

-Buck
Callsign: Buckaro(o)
Author: Lockheed 1049H Constellation, Grumman Goose, MD-81, Edgley Optica, Velocity XL RG, YASim Guide
User avatar
Buckaroo
 
Posts: 475
Joined: Fri Jan 18, 2008 6:45 am
Location: Bloomington IN USA
Callsign: Buckaro(o)
Version: 2.10
OS: Windows & Linux

Re: Can we use a faster 3d model format

Postby Johan G » Sun Aug 16, 2015 11:23 pm

There would be one significant drawback with using an OSG native format: Backwards compatibility. Imagine that there would be a breaking change five years ahead with only buggy converters... :roll: ;) "Who on Earth would use decade old models in a game?!"

Edit: Also the only documentation of the native ascii, binary and xml formats seem to bee the source code (stated explicitly for the .osg format in the OSG FAQ). *sigh*
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Johan G
Moderator
 
Posts: 5534
Joined: Fri Aug 06, 2010 5:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 3.0.0
OS: Windows 7, 32 bit

Re: Can we use a faster 3d model format

Postby hamzaalloush » Mon Aug 17, 2015 12:26 am

yeah i agree with Johan G, seems future-proof to think about all the contribution of models that people made in the past,
to my little knowledge of 3d model formats, AC3D seems, like Buckaroo mentioned, easy to parse, read and AFAIK written in ascii, where it would show diffs properly in versioning systems(for example for someone who wants to check for changes in material color, texture attributed to a model, etc, that would be very easy in the first line of code, so in git you would see the changes highlighted at the top)...

are other 3d model formats binary for instance? (i'm not sure, i'm only a noob at this).

also, another reason that AC3D is still used aside from working good, might be for historical reasons, as it was supported with PLIB.
hamzaalloush
 
Posts: 632
Joined: Sat Oct 26, 2013 9:31 am
OS: Windows 10

Re: Can we use a faster 3d model format

Postby LesterBoffo » Mon Aug 17, 2015 12:29 am

My short reply, no way! :roll:

Not when I have to search down another 3D file converter that doesn't appear to be supported by older versions of Python and Blender.
User avatar
LesterBoffo
 
Posts: 2105
Joined: Sun Oct 02, 2011 4:02 pm
Location: Western USA
Callsign: LesBof
Version: 2016.1
OS: WinXP 32 bit

Re: Can we use a faster 3d model format

Postby Thorsten » Mon Aug 17, 2015 5:32 am

The current format we use (ac) seems to slow down FG like pond of treacle. It might be something else of course, but lets treat the 3d model format as the scapegoat.


I've heard the same claim about Nasal, the way we render clouds, the usage of png vs. dds textures, bad design of scenery model xml, the inefficiently structured code in general, the fact the we don't require OpenGL 3.0 and higher in particular and a host of other things.

Allow me to *yawn*.

If you want to find out why FG slows down, learn to analyze a problem. Set up a benchmark situation, produce standardized data, link that with your tested settings and try turning it into evidence and form a testable hypothesis backed up by your evidence - then the people who matter will take you seriously.

Or, if you feel unable to do so, kindly leave the problem to the people who can identify the bottlenecks.

I am curious at the difference in load-times, if anyone happens to have data.


For a fair share of models, you should be worried about the texture loading time rather than the mesh loading time - and even there we intentionally prefer png over rgb (which loads about two times faster last time I tested) in most cases to conserve harddisk space.
Thorsten
 
Posts: 11123
Joined: Mon Nov 02, 2009 8:33 am

Re: Can we use a faster 3d model format

Postby Buckaroo » Mon Aug 17, 2015 5:35 pm

Thorsten wrote in Mon Aug 17, 2015 5:32 am:
I am curious at the difference in load-times, if anyone happens to have data.


For a fair share of models, you should be worried about the texture loading time rather than the mesh loading time - and even there we intentionally prefer png over rgb (which loads about two times faster last time I tested) in most cases to conserve harddisk space.


I don't agree with the original poster's assumption, but while one factor may certainly have a greater impact or cost over another, it should not deter anyone from a reasonable interest in other numerics.

Luckily I have some knowledge of image file formats and their effects on load-time and memory usage due to my field of work.

-Buck
Callsign: Buckaro(o)
Author: Lockheed 1049H Constellation, Grumman Goose, MD-81, Edgley Optica, Velocity XL RG, YASim Guide
User avatar
Buckaroo
 
Posts: 475
Joined: Fri Jan 18, 2008 6:45 am
Location: Bloomington IN USA
Callsign: Buckaro(o)
Version: 2.10
OS: Windows & Linux

Re: Can we use a faster 3d model format

Postby Jabberwocky » Mon Aug 17, 2015 8:28 pm

The loading times are kind of irrelevant. The whole time, a model loads, even the heaviest that come to my mind, like 777 or 707 with their very detailed cockpits is nothing compared to the loading time for the scenery. So, even if we could, for an extreme detailed model get 10% better loading speed with another format and we start that plane then for example on KPHX, what would we effectively win? 1/10 of a second? Maybe even 2/10? And once the plane is loaded, all geometry is in the memory in objects which has nothing to do with the file-format. The textures seem to be a different matter, but then, we all like highe quality textures because it simply looks better and the loss in appearance would be probably more painful than the win by lower quality textures.
Jabberwocky
Retired
 
Posts: 1319
Joined: Sat Mar 22, 2014 7:36 pm
Callsign: JWOCKY
Version: 3.0.0
OS: Ubuntu 14.04

Re: Can we use a faster 3d model format

Postby Thorsten » Tue Aug 18, 2015 5:40 am

There are some 20 to 50 MB meshes in the repository (Vitos is fond of making those - Vostok has quite a number of vertices). The loading times supposedly matter to people doing MP (I have no first-hand experience of that, that's why 'supposedly') since they experience a delay every time an MP plane comes into view, which, again supposedly, is rather annoying.

So there's virtue in improving loading times even if there is no relevance whatsoever for framerate.

Loading times for textures are at times dramatically different dependent on file format - I think pre-mipmapped dds has a factor five to ten over png which is very noticeable. I suspect that the potential gain for mesh loading in a more native format for the renderer is of similar order.

I hold to my statement that usually it is texture and not 3d mesh which dominates the loading times - with a handful of exceptions mentioned above.

In general, the question of what strategy to use is driven by more than one requirement. In the case of 3d models, the choice of png is due to compatibility requirements (compressed dds is a proprietary format and can't be easily used by OpenSource drivers) and due to storage space / distribution bandwidth requirements (uncompressed dds is very large, rgb is still large). We are using rgb textures in contexts where loading speed matters a lot - weather for instance cycles lots of textures in and out of memory and the drag by using png has been found to be quite an issue.


I don't agree with the original poster's assumption, but while one factor may certainly have a greater impact or cost over another, it should not deter anyone from a reasonable interest in other numerics.


I'm not saying it is unreasonable, but I suspect it is not the determining factor, and I don't know the numbers because I have never tested for that very reason.
Thorsten
 
Posts: 11123
Joined: Mon Nov 02, 2009 8:33 am

Re: Can we use a faster 3d model format

Postby Jabberwocky » Tue Aug 18, 2015 9:35 pm

I fly a lot in MP. Now here is the rub: The program determines a new plane is in sight according to the settings in LOD ranges. Which is often a distance that make a plane look like two or three pixels big. So at the time, the loading of this model starts, I annoyingly miss a two, maybe even four pixel big plane on the sky I hadn't noticed in the first place. Till it comes nearer that there is acutally something to see, it is already fully loaded anyway.
The real annoying thing is, that FG lags when big models are loaded. The solution for that wouldn't be another 3d format though but to place the model loading in another thread. And if you are near to the ground, you have this lag effect quite often anyway, it's not the planes it's often the scenery (and yes, that happens then in SP mode the same).
Jabberwocky
Retired
 
Posts: 1319
Joined: Sat Mar 22, 2014 7:36 pm
Callsign: JWOCKY
Version: 3.0.0
OS: Ubuntu 14.04

Re: Can we use a faster 3d model format

Postby japreja » Sat Sep 19, 2015 3:40 am

I think several things can be optimized to load faster, not just the 3d format. Regarding 3D model format I think any improvement in speed would be in the order of nano or micro seconds during loading if a binary format was chosen. I have heard that several 3D model developers improve performance of models by using a Texture Atlas. I would only imagine that a Texture Atlas would be fairly painful to manage during the development of the 3D mesh and I would not personally do it for anything until the 3D model is in the final stages and will not change but nearing a public release.

This should also apply equally well for scenery but since the scenery is loaded/unloaded depending on location it may be difficult to put together an atlas that is global. Scenery loading would have to test, preemptively, which textures are upcoming while also keeping track of which textures are no longer needed and add remove from the atlas dynamically. Doing all of this might improve scenery loading times. I say "might improve" simply because this process would take additional time to complete which might nullify any intended improvements.

Outside of 3D meshes, any C/C++, or any other language, function that loops several times during the simulation would greatly benefit by using hand optimized Assembler. For FlightGear I think that would be with screen drawing and maybe scenery loading. Some of this would fall upon 3rd party libraries that handle the various FlightGear tasks multiple times per second and would also need to be improved. Most modern C/C++ compilers handle the code quite well and eliminate the general need to do this. The pitfalls with manual optimization of assembler is that it would be required for each CPU/GPU supported across the multiple platforms and the fact that well experienced Assembly Programmers are only a few hundred on the planet.

A Bell Labs quote from the past
"Some languages are designed to solve a problem. Others are designed to prove a point."


All speed optimizations should consider assembler as an option (at least when a C/C++ function is in a working and final state)... It is literally the only language a CPU/GPU has embedded into it.
japreja
 
Posts: 331
Joined: Thu May 07, 2015 11:05 pm
Location: MT, USA
OS: Windows 10 Pro 64bit

Re: Can we use a faster 3d model format

Postby Thorsten » Sat Sep 19, 2015 4:59 am

FYI, James at some point had plans to do the terrain texturing by texture atlas. So that optimization may come.
Thorsten
 
Posts: 11123
Joined: Mon Nov 02, 2009 8:33 am


Return to Development

Who is online

Users browsing this forum: No registered users and 2 guests