next »

[oahda]

And what would be the best way to achieve that the right string is read in the file? With using a stream reader? I'm using C#, by the way.

Shameless plug, but here's my (WIP, but probably still good enough for something simple) solution: https://forums.tigsource.com/index.php?topic=56749.0

[_glitch]

Thank you! This should help me.

[oahda]

What 3D model formats do people use (with the whole deal, from geometry itself to animations and bones) for games, especially custom engines? I like FBX, but I read just now that it's a bit generic/bloated and is really meant to serve as a way to transfer models between different modelling packages and the like, rather than for use in games and so on. Thoughts? Ideas?

[gimymblert]

Storing 3d data isn't complex either, it's just a fat list of vertex their attribute then a list of triple vertex index call triangles, the only shady things is animated bones (but vertex are the one that store references to bone) and yet that's basically the same thing (list of transform with animation keys), list of lists. I see a lot of people using OBJ, but it don't store animations. Some use collada because XML. It will depend on your need, you can use custom, I'm not sure how you would import stuff like material since everybody want to do it differently.

[oahda]

Yeah, it's the animations and all that sort of stuff that scares me.

I suppose I might have to learn anyway unless I can find something better tho. I'm messing with assimp for loading 3D now, but I can't easily just add it to my project, but need to make it first and then link against it, which requires at least on OS X that I also link against zlib, and it's just... such a hassle when I want my engine to be as lightweight and self-sustained as possible.

[Sik]

The problem with this is that pretty much everybody will tell you to use your custom format and ideally just a raw dump of values you can transfer as-is to the GPU (・～・) (what could go possibly wrong?)

And yeah it's annoying but the only other formats commonly used are OBJ (primitive and not representing how GPUs work) and COLLADA (which is the most overengineered bloatfest ever and many programs don't even export it properly anyway ).

I made a custom text format called ZXM and a libzxm library to go along with it, but then I stopped bothering with the idea of toying with 3D so right now it's not really better than OBJ aside from being somewhat more GPU friendly >_> (only triangles, shared vertices have to share all their properties much like how they'd be in the vertex buffer - so you can just use the data as-is at least) I've been meaning to add animation but I never settled on what to use (not sure if to store matrices, quartenions or translation/scale/rotation) Either way I can upload what I have if you want to try it.

Obligatory quad:

Code:

ZXMESH

vertices x y z nx ny nz u v r g b a b1 b2 b3 b4 w1 w2 w3 w4
* 32 0 -32 0 1 0 1 1 1 1 1 1 0 0 0 0 0 0 0 0
* -32 0 -32 0 1 0 0 1 1 1 1 1 0 0 0 0 0 0 0 0
* 32 0 32 0 1 0 1 0 1 1 1 1 0 0 0 0 0 0 0 0
* -32 0 32 0 1 0 0 0 1 1 1 1 0 0 0 0 0 0 0 0

faces v1 v2 v3
* 0 1 3
* 0 3 2

I also wanted to make an exporter for Blender (and ideally an importer) but I have no idea about Python and much less how the Blender API works, looking at the OBJ exporter didn't help much =P

[BorisTheBrave]

such a hassle when I want my engine to be as lightweight and self-sustained as possible.

If it's any consolation, you need zlib to load png's too, so it is a dependency that is virtually impossible to avoid.

I did use tinyObj for a while as a mesh loader as it has no dependencies, but it can only load obj files, so I think assimp is generally the better choice.

[oahda]

If it's any consolation, you need zlib to load png's too, so it is a dependency that is virtually impossible to avoid.

Hm... I've been loading PNG files just fine with both SDL2_image and Tom Dalling's Bitmap class without explicitly linking against zlib... Maybe it's implicitly there somehow, but when I added assimp I had to explicitly link against zlib or I'd get linker errors. Any explanation? o_q

The problem with this is that pretty much everybody will tell you to use your custom format and ideally just a raw dump of values you can transfer as-is to the GPU (・～・) (what could go possibly wrong?)

Yeah, thought so.

I also wanted to make an exporter for Blender (and ideally an importer) but I have no idea about Python and much less how the Blender API works, looking at the OBJ exporter didn't help much =P

Yeah, working in Blender and having Unity automatically update models as I save the file so long as it's in the project has been a great process for me lately. So for a custom 3D engine too I'd love to use Blender files at least for development and then have them converted into something minimal for deployment.

But I see no reason not to use an existing format if it does the job well and does all the scary stuff for me, like saving animations and whatnot, especially if it means I can export straight from Blender (I'll still have to do manual work making the engine display the animations correctly, so might as well piggyback halfway there).

Assimp actually can load Blender files, but only incompletely at the moment (no animations for example).

[JWki]

Well most engines don't really deal with individual files anyways and instead package assets into huge binary files.
No serious engine I know directly deals with third party file formats at runtime, instead they have tools that import any number of third party formats like .fbx and export a custom binary format to use in the runtime.
This has various reasons - they tend to do LoD calculations and various other optimizations at this point, optimize the asset for the target platform because you might have different data for PS4 and Desktop PC for example, and also in general it makes sense to have a format that you can just directly load into the data structures used in the runtime. You really really don't want to have to do a lot of parsing when loading models, textures, or anything at all really - most runtime formats have a very minimal header that provides information about the memory required to store the asset and some metadata, and then just a big fat blob containing vertex and index data, etc.

On animations, those you probably don't want to store alongside vertex data usually because you might want to retarget animations to different meshes so you usually want to have a seperate file for animation data.

Essentially what makes most sense is to have an external tool that can import all the file formats you wanna support, with .fbx being a good choice for a primary format because there's an SDK that you can use and most tools can export .fbx, and then in your actual engine, only use your own, optimized format. This moves all the hassle from runtime to production time which is always a good thing.
Oh and that also allows you to solve issues like for example how different rendering APIs handle textures because you should know at production time what API you use on what platform so you can essentially just always have the correct layout for the API you're building for.

[oahda]

Those are very good points. I guess I'd want my engine to be flexible depending on how serious and big any given project is. If I just want to do something quick and non-commercial and slap on some files I exported from Blender then I want to be able to do that with no effort involved, but for something big it should also be able to do what you're saying, I guess.

[JWki]

I can also recommend this file format for prototyping and playing around with asset management:
https://github.com/uberpixel/SGM-file-format

It's quite simple and fast to parse and comes with blender export scripts for both the animation and the mesh format.

[qMopey]

such a hassle when I want my engine to be as lightweight and self-sustained as possible.

If it's any consolation, you need zlib to load png's too, so it is a dependency that is virtually impossible to avoid.

I did use tinyObj for a while as a mesh loader as it has no dependencies, but it can only load obj files, so I think assimp is generally the better choice.

You can write a zlib/png loader, or use one like this: https://github.com/RandyGaul/tinyheaders/blob/master/tinydeflate.h. No crazy zlib or libpng over-engineered messes, just included header and go.

[Sik]

Well most engines don't really deal with individual files anyways and instead package assets into huge binary files.

Those are more akin to stuff like ZIP though, the actual data is still extracted individually from these. The big advantage of having those huge archives is that you only need to open one file and keep it open (opening files is an expensive operation, especially awful if you're dealing with tons of small files).

[gimymblert]

To add to 3d confusion, fuck Z = up vs y = up (and double fuck the fucker who occasionally make x = up), fuck XYZ, ZYX, ZXY, etc ... and fuck right hand, left hand coordinate

There I said it

[BorisTheBrave]

If it's any consolation, you need zlib to load png's too, so it is a dependency that is virtually impossible to avoid.

Hm... I've been loading PNG files just fine with both SDL2_image and Tom Dalling's Bitmap class without explicitly linking against zlib... Maybe it's implicitly there somehow, but when I added assimp I had to explicitly link against zlib or I'd get linker errors. Any explanation? o_q

SDL2_image is distributed with zlib1.dll. You are presumably using pre-compiled binaries that have been already linked against that - hence no need for you to do anything explicit. I'm saying seeing as you *already* have that dependency, you needn't consider it a downside of other libraries if they also link against it. But they may require more configuration than SDL2_image.

[oahda]

If it's any consolation, you need zlib to load png's too, so it is a dependency that is virtually impossible to avoid.

Hm... I've been loading PNG files just fine with both SDL2_image and Tom Dalling's Bitmap class without explicitly linking against zlib... Maybe it's implicitly there somehow, but when I added assimp I had to explicitly link against zlib or I'd get linker errors. Any explanation? o_q

SDL2_image is distributed with zlib1.dll. You are presumably using pre-compiled binaries that have been already linked against that - hence no need for you to do anything explicit. I'm saying seeing as you *already* have that dependency, you needn't consider it a downside of other libraries if they also link against it. But they may require more configuration than SDL2_image.

Well, I'm on OS X. But something similar perhaps, yeah. But tinydeflate looks cool! The reason I currently prefer Tom Dalling's Bitmap class (despite the name, it loads PNG files too) is that it also has code to figure out the format for OpenGL. Well, that's really the thing that it does do on its own, and then it uses stb_image to do the loading apparently. I'm including the (three) files directly into my project, so no prebuilt binaries or anything. Not sure what stb_image does under the hood, if it uses zlib or rolls its own.

[qMopey]

tinydeflate is very similar to stb_image. They both are doing nearly the same thing as far as loading PNG goes. tinydeflate has less code, and that's pretty much the only advantage it has over stb_image. If you're already using stb_image there's no good reason to switch, other than preference. Both implement a custom zlib decompressor. PNG compresses pixels with DEFLATE (zlib), which is why libpng has a zlib dependency.

[JWki]

I just love the stb libraries - header-only without dependencies is my favourite library style by far.
And no offense to Randy but I also like them because I know the author is incredibly capable and experienced so they're very likely to be efficient and sufficently bug-free.

[qMopey]

Hopefully more people become inspired by stb libraries and make some more. It would be fantastic to construct the majority of a game engine with single file libraries. Writing build systems becomes easier, compile times rise due to less translation units. stb libs are so solid it only really makes sense to create different libs than to compete directly.

I was personally considering doing a tile + collision detection header. I think the a big one would be an OpenGL wrapper as a header, something that could render text, do sprite batching, layers/sorting/z ordering, etc. Anyone else have a wish-list or ideas?

[oahda]

Yeah, I'm really liking these lightweight libraries. Trying to modularise my own code similarly too, so that anything that could be handy for standalone use can be picked out without being stuck in dependency spaghetti. c: