• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
3Ddreamer

File Formats for 3D Game Performance

16 posts in this topic

Good day, everybody [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img]

Opinions very, but I would like to get experienced ones on which 3D object file formats-including for terrain, vehicles, trees, and so forth-result in the best performance, all other things being equal. This is the general question.

The more specific question is, which file formats for 3D objects make better performance for the C# based games which I will be creating?

Why in the world would any game developer use 3ds file format? Is there some kind of performance advantage because it conforms to the old naming conventions?

The 3D model game file formats which I have used are 3ds, obj, x, and a proprietary one not published yet, so I have some experience.

Any and all comments, discussions, and criticism is welcome as long as it is somehow related.


Clinton
0

Share this post


Link to post
Share on other sites
Uh, the file format will have zero impact in actual rendering performance, as the model will be converted to the program's internal format regardless of the original format. As for loading performance, it really depends, binary formats are usually the fastest, and also take the least space on disk, but are comparatively much harder to parse.

For instance, many people use .obj not because it is fast, but because it is very easy to parse, readily editable by any text editor, and is usually good enough for most models even if it is quite wasteful in terms of storage. But loading the same model from a .obj and from a .3ds will yield the exact same model representation in your game's memory and there will be no performance difference after loading is complete.
2

Share this post


Link to post
Share on other sites
[quote name='Tom KQT' timestamp='1349245980' post='4986300']
[quote name='Bacterius' timestamp='1349243010' post='4986291']
binary formats are usually the fastest, and also take the least space on disk, but are [b]comparatively much harder to parse.[/b]
[/quote]
Hm, I would say the exact opposite (talking about the parsing part).

Text formats are easier for human to read and understand, but reading them from a code is harder because you must do some string processing, finding keywords etc. and last but not least - converting textual representations of numbers into actual numbers.

Binary formats are nearly impossible for a human to read. But for a computer code it's usually very easy. Specifically when talking about 3D mesh formats, there isn't much surplus information in the binary files, all you need to know is that for example the first 4 bytes represent the number of faces, then you have 3*4 bytes for a normal vector, then 3*3*4 bytes for 3 vertices or a face etc etc etc (simplified example of a binary stl).
And when reading those bytes, for example 12 bytes of a normal vector, you can directly use this data to fill your vector structure in the code, no processing needed, just file.read or memcpy.
[/quote]
Well, theoretically I would agree with you (and your explanation is correct) but usually, textual formats are left as simple as possible because, well, optimizing something that isn't meant to be fast is contradictory, whereas binary formats are usually much more complex as they feature stuff like binary compression, recursive model structures, special constructs, etc... to make them even more efficient. They also often contain tons of metadata.

In short, I correct my statement: binary formats often contain much more stuff to parse, but are indeed easier to parse by a computer.
0

Share this post


Link to post
Share on other sites
[quote name='Hodgman' timestamp='1349273332' post='4986384']
...clever binary casting techniques, etc...[/quote]

Can I ask how you handle writing out objects that are runtime-dependent? (I may be making a false assumption here, as well). I was under the impression that things like buffers and Texture objects that require a device context to create are volatile "memory-only" elements. That's one thing I still do in my onLoad methods from the binary format: create the device-contextual buffers via the game's DX11 device before handing off the object reference.

Am I completely off-base in my understanding of these objects? Or is the data valid, and I just need to do what you mention and correct the buffer's internal relation to the device that will render it? Edited by BCullis
0

Share this post


Link to post
Share on other sites
[quote name='BCullis' timestamp='1349273653' post='4986387']Can I ask how you handle writing out objects that are runtime-dependent? I was under the impression that things like buffers and Texture objects that require a device context to create are volatile "memory-only" elements. That's one thing I still do in my onLoad methods from the binary format: create the device-contextual buffers via the game's DX11 device before handing off the object reference.[/quote]Yes sorry, [b]most[/b] of these structures don't require a parsing step. The above structure does perform the pseudocode of [font=courier new,courier,monospace]for each program: program.handle=device.Create(code[program.offset]).[/font] [font=courier new,courier,monospace]free(code)[/font]. i.e. yes, D3D objects must be created and destroyed. However, this is from the D3D9 version of my shader format, so CBuffers specifically don't have to be created via D3D ;)
Side note - on consoles with nicer graphics APIs, this is isn't required ([i]all that's required is pointer-patching to where you streamed the VRAM data instead[/i]). Edited by Hodgman
1

Share this post


Link to post
Share on other sites
Having written a loader for the 3ds format I heartily recommend avoiding it if possible. It's an old format with limitations that might cause you problems over a newer format.

For example: 1) All filenames are in 8.3 format, and saving a .max file into .3ds normally truncates the filenames if they are longer than 8.3, which can lead to loss of data if you have a prefix. (Learnt that one the hard way).
2) The maximum number of vertices per object is 65536, which might be a problem depending on how high resolution your meshes are.

My current project uses .obj files because they are easy to parse, pretty much every modeller can save them, and I'm still early in development. Pretty soon I'll have to start using a format with more features such as collada, since .obj doesn't support bones or keyframes etc. But my plan is to convert the collada files into my own format during a resource build phase as others have suggested.
1

Share this post


Link to post
Share on other sites
[quote name='Bacterius' timestamp='1349243010' post='4986291']
Uh, the file format will have zero impact in actual rendering performance, as the model will be converted to the program's internal format regardless of the original format. As for loading performance, it really depends, binary formats are usually the fastest, and also take the least space on disk, but are comparatively much harder to parse.

For instance, many people use .obj not because it is fast, but because it is very easy to parse, readily editable by any text editor, and is usually good enough for most models even if it is quite wasteful in terms of storage. But loading the same model from a .obj and from a .3ds will yield the exact same model representation in your game's memory and there will be no performance difference after loading is complete.
[/quote]

This is not always the case. For example, if there needs to be a file loaded during run time. Such as a cache miss, if you are running low on resources, your cache may not load some resources until it needs it at run time, or may unload something to make room for a different resource. This causes a load during run time and can effect performance. It can be avoided most of the time in a well written cache system but not always.

Even triple A games suffer cache misses occasionally.

So in this scenario a 3d binary format will effect performance far less, than a slower to load exchange format.

So like I said it depends on the internals of what your program is doing under the hood with resources. Edited by EddieV223
1

Share this post


Link to post
Share on other sites
[quote name='EddieV223' timestamp='1349326834' post='4986653']
[quote name='Bacterius' timestamp='1349243010' post='4986291']
Uh, the file format will have zero impact in actual rendering performance, as the model will be converted to the program's internal format regardless of the original format. As for loading performance, it really depends, binary formats are usually the fastest, and also take the least space on disk, but are comparatively much harder to parse.

For instance, many people use .obj not because it is fast, but because it is very easy to parse, readily editable by any text editor, and is usually good enough for most models even if it is quite wasteful in terms of storage. But loading the same model from a .obj and from a .3ds will yield the exact same model representation in your game's memory and there will be no performance difference after loading is complete.
[/quote]

This is not always the case. For example, if there needs to be a file loaded during run time. Such as a cache miss, if you are running low on resources, your cache may not load some resources until it needs it at run time, or may unload something to make room for a different resource. This causes a load during run time and can effect performance. It can be avoided most of the time in a well written cache system but not always.

Even triple A games suffer cache misses occasionally.

So in this scenario a 3d binary format will effect performance far less, than a slower to load exchange format.

So like I said it depends on the internals of what your program is doing under the hood with resources.
[/quote]

I don't see what cache misses have to do with the storage formats, you don't reload data from disk on a cache miss, the CPU cache pulls data from RAM on cache misses(This is automatic) and the only thing that matters for this is the internal (in memory) format.

If you are streaming data in and out of the system at runtime then yes, you need a efficient storage format and it might even be worth storing the data in a compressed form and decompress it as it loads (depending on how much free CPU resources you have), runtime streaming of data from disk however is only really needed for large open world games (or consoles such as the xbox360 since it has almost no RAM)
If you have a software cache to stream data in and out at runtime you're
0

Share this post


Link to post
Share on other sites
[quote name='SimonForsman' timestamp='1349333532' post='4986671']I don't see what cache misses have to do with the storage formats[/quote]After you've streamed your stored bytes into memory, you've got to do some work with them. Depending on what that work is, and how the file is laid out, you'll get a different amount of cache misses during that work.
[edit]Ah, i see he's talking about a software resource cache, not the CPU's RAM cache... In that case, smaller more compact file formats would allow you to fit more files in your 'resource cache' at a time, whereas large bloated formats would waste memory and fill up your resource budget ([i]requiring less resources to be loaded at once, requiring more streaming[/i]). Edited by Hodgman
0

Share this post


Link to post
Share on other sites
[quote name='Hodgman' timestamp='1349334765' post='4986676']
[quote name='SimonForsman' timestamp='1349333532' post='4986671']I don't see what cache misses have to do with the storage formats[/quote]After you've streamed your stored bytes into memory, you've got to do some work with them. Depending on what that work is, and how the file is laid out, you'll get a different amount of cache misses during that work.
[/quote]

The post i replied to though seemed to imply that you'd[b] reload[/b] the data from [b]disk[/b] on a cache miss. (Maybe i just misunderstood it)
0

Share this post


Link to post
Share on other sites
[quote name='SimonForsman' timestamp='1349337162' post='4986680']
[quote name='Hodgman' timestamp='1349334765' post='4986676']
[quote name='SimonForsman' timestamp='1349333532' post='4986671']I don't see what cache misses have to do with the storage formats[/quote]After you've streamed your stored bytes into memory, you've got to do some work with them. Depending on what that work is, and how the file is laid out, you'll get a different amount of cache misses during that work.
[/quote]

The post i replied to though seemed to imply that you'd[b] reload[/b] the data from [b]disk[/b] on a cache miss. (Maybe i just misunderstood it)
[/quote]

This is the way it works. You can't put everything in memory at a single time for large games, especially open world games, their resource managers ( caches I've been calling them ) work over time to keep what you need in memory and remove what you don't. But they are never perfect in that they often "Miss" and have to wait to load from disk.

Having another thread for loading of uncached resources can help, but then you deal with pop in's and things like that. Edited by EddieV223
1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0