Sorry your browser is not supported!

In App Game Kit and App Game Kit Studio we could use Game Guru models and also First Person Creator (Classic) models.

But how? With App Game Kit Studio it is much easier to preview *.x-files and texture files and import them into your own project.
But it is also not perfect and we would have to do a lot of searching and copying by "hand".

Also there is a lot of free content for our own projects on GitHub.
https://github.com/TheGameCreators

https://github.com/TheGameCreators/FPS-Creator-Classic
First Person Shooter Creator (Classic) and also Dark Basic Professional and a lot of model-packs are there for download.

But they are from a time, where UHD 4K monitors or high resolution where not such a big deal. So previews for the models are often stored in 64 x 64 pixel bitmaps *.BMP

.... there is also Game Guru Loader if you have GameGuru Levels and so on to convert them into AGK. For me often was the problem that GameGuru didn't run well on my system, and I didn't figured out why.
I tried FPSC Classic and the FPS Creator X10 version
https://www.amazon.de/Modern-Games-FPS-Creator/dp/B000BCE9SQ/ref=sr_1_1?__mk_de_DE=%C3%85M%C3%85%C5%BD%C3%95%C3%91&keywords=fps+creator&qid=1559490365&s=software&sr=1-1-catcorr

https://www.amazon.de/The-Game-Creators-FPS-Creator/dp/B001F2S0P4/ref=sr_1_1?__mk_de_DE=%C3%85M%C3%85%C5%BD%C3%95%C3%91&keywords=fps+creator&qid=1559490365&s=software&sr=1-1-catcorr


And they work better on my system, but also not perfect. They provide on the CD about 1 GByte of 3D models, characters, textures, sound, music and so on and with all model-packs, where a lot of are now free, there are assets about more than 8 GBytes in total.

In 2016 they where made free.

So my idea was, what if ... we could have something like an easy level builder and or props-placement tool for the FPS Creator (Classic) assets for AGK. And since AppGameKit is also available for Raspberry Pi and Android, my idea was even "bigger". What if, we could use the assets on the go?

Since 2014 I tried to run a 3D game on the OUYA. It was build in AppGameKit 1.x and uses the FPSC2AGK ... it somehow worked. But I could not edit the code for my need and the loading times where big on the OUYA. I also noticed that the objects are pre-baked now and a lot of the textures are loaded multiple times and also objects and textures are stored multiple times.
So an easy scene which was about 10 pre-fabs from FPSC was now about 380 objects and textures. So the media folder was big and also the loading times.





So. On the one hand, we had a program, that converted FPSC to AppGameKit, and we had GameGuru Loader much later. But they don't fitted my needs.

What I am was looking for was such thing like a FPSC on the go with a little foodprint running on low-spec hardware with a lot of models and other assets.

Whaaaaat? That is not possible!!!

I never got AppGameKit executables to run on a Raspberry Pi, guess some problems with rights management, but I had my OUYA as reference. And my goal was, to run things on the OUYA and so I now, it could run on all other platforms.

____________________________________________
____________________________________________

So how? First I analysed the FPSC (Classic) Data, and found out, that *.DDS are most of the space in use. AppGameKit itself can't use *.DDS, so there are two options: PNG or JPEG. BMP also, but that makes not much sense in most cases.
JPEG is fine, but can't do transparency and PNG is very slow when it decodes in memory while loading.
On ARM devices JPEG is also much faster than most PNGs I tried.

I started the work on this project before AppGameKit had "RAW:" in file-operations. So some of my tools are written in PureBasic.

What is the goal or what could be the goal?

Android apps had to be about 100 MB at all and I found, 100 MB is a good size, even if we have no ZIP 100 floppys anymore
So we have ~ 8 GB on model packs or 1 GB assets with FPSC (Classic), and I wanted to try, if it is possible to get it under 100 MB ...
That is insane!!

I figured out, that a lot of the *.X files from FPSC(C) are mostly doppelganger. And the FPE files have only some differences.
I also figured out, that also the textures are in some cases are doppelganger and they also not so different from each other.

I also saw, that we have mostly four textures, also we could reduce them to one only. Why? _D, _N, _S / _I and _D2 for mobile devices and also mobility, that would be enough.
That would make only 1/4 of the size. The next thing would be, that we could reduce the texture quality in X and Y size (UV), we don't need 4K x 4K most of the time. Not all textures are so high, but some are. We don't need 2K x 2K for a gun or a hammer, if we only this prop from the far.
So in the worst case, we could say we could reduce also the texture in quality to 1/4 and the next test was, from *.DDS to JPEG, we could have about halfe the size on the JPEG with nearly the same quality.

So, from ~ 1,000 MB ==> 1/4 * 1/4 * 1/2 ~ 1/32 ~ 31.25 MB
In theory. Also we have doppelganger. Some walls use the same texture, but they are in other folders, some props have the same texture, but with other names. And so on.

What about the 3D models? *.X files?

I figured out, that we could reduce the size from *.X files, if we use SetObjectMeshFromMemblock()
Or if we use e.g. FragMotion and save the X-file as:

Format: compressed
Rotation Type: Quaternion

unfortunality not every X-file model works after that. Also the memblock-functions are only for meshes, not for animations or combined meshes.

I also tested some animated models. Most models have about 2498 keyframes. And have about 100 animations inside, but they are mostly doppelgangers, because the are combined from food and hands like:
walking without gun, walking with gun, walking with bazooka, walking with granade, walking with MG, walking with rifle ...
running without gun ....
swimming without gun ...

And also there are a lot of keyframes, from a time, where transitions from keyframe to keyframe maybe are cost to much GPU power. Since AppGameKit is able to tween animations, this could be reduced drastlicy.

e.g. Specialist.X is about ~ 3 MB original from "Modern Day"
With FragMotion without changing something, but compressing the X-file it is about 1.8 MB (no ZIP, direct loading in AppGameKit possible)

And if we would have only about 30 Keyframes the file would be 107 kByte. That would be not practical, but for testing, I tried that. A "frame" "costs" about 500 bytes. I guess, we could have abput 100 seperate animations with less keyframes and our new model would be about under 300 kByte big. (including the mesh, weights, bones)

The Audio? We could save most of the files as *.OGG

So there is a lot of potential to compress and reduce the file size of the assets.

---------------------------------
---------------------------------

How, what, why?

Taget: 100 MB.

FPSC + free Model packs has over 8000 assets (with doppelgangers)

5221 (modelpacks) *.FPE (pre-fabs, models and there behavior and offsets)
2978 (modelpacks) *.FPS (segments like walls, bigger building-structures, working doors)

581 (FPSC(C)) *.FPE
316 (FPSC(C)) *.FPS

374 (FPSC(C)) *.WAV

Not every asset is a great asset. Some of them are currupt, they don't load in AppGameKit or in other programs correctly. Some of them may not fit for educational purpose (Nazis e.g.) some don't fit to the others because of there polycount. They may have to much or to less, to blend seamless.
So let's they, without doppelgangers and a good variaty and maybe the better looking ones, we could count to 1,000 assets.

The idea is, to have about 1,000 assets that fit into less then 100 MB.
For texture work we could be about ~ 30 MB, for sounds we could have about 3 MB (without music, music would be another thing. More like Amiga MOD, MIDI, or MO3)
Maybe Speech synthesis for one character ~ 20 MB good quality.
the 1,000 models in size about 30 MB for the non animated ones
and about 15 MB for the app itself.

Let's say we have no Speech synthesis yet or could use build in from Android. We could have about 30 unique animated characters for about 300 kByte each under 10 MB.

But that is all theory.

___________________________________________________________________________________

Steps to achieve that.

- download the FPSC(C) and FPSC(C) model packs
- convert the textures to PNG without loss (better would be, we would have the TIFF or TARGA files from the source, not the compressed *.DDS DXT with artifacts already)
--- (here we also have no *.basis in AppGameKit, what is pitty ----
- creating bigger previews than 64 px by 64 px so we could use the file-explorer from e.g. Windows or the finder on MacOS X
- loading the previews, sort the better objects and models : I have a tool for that
- copying the models and textures into new folders
- easy loading

build a new model placement tool with "URL"s kind of reference. These ~ 1,000 models would have a unique ID all over and we could use them in AppGameKit, AppGameKit Studio, AppGameKit APP and so on, but only have to copy the source, because on mobile and everywhere, we could have these 100 MB assets already installed.
And if not, we could download it fast, because only 100 MB in a package.

All new demos and tutorials could work with that.

AND !!! --> because we know, from which source every object is and which texture was used, we could recreate the _D, _N, _S and so on textures and high-resolution textures from the 8 GByte assets, if we would need to have more quality or "better" lighting effects and so on.

Screenshots so far from the tools and tests, and also very early placement editor without any placement functions and no structure

Seperate, because that are documents.

2019_Mini_Guru_Placement_Editor: English, a little tutorial how to setup the FPSC(C) and model-packs from the GitHub, and later for use in my tools

Auswertung_FPSC_Classic_OhneWeitereModel-Packs_2019.xlsx: Excel sheet with some math where you can see how the data space is used in FPSC(C)

Bachelorarbeit_Folker_Linstedt_Machinima: German, title: Anwendung von Machinima-Methoden für die Datenreduktion beim Storytelling auf einer Mikrokonsole

My bachelor thesis: Usage of Machinima methods in favor of data-reduction in story telling on a microconsole

I wrote about the OUYA, set top boxes and how it would be possible, to use some kinds of Machinima and game engines to use less band width for "animations"/"movies" or like in the title: for stoies that has to be told.
It's written in German. I am setting the OUYA and Raspberry Pi and Amazon FireTV Stick in the same category. I could said that also the Playstation Classic and or the SNES / NES mini are microconsoles, but they have no internet connection, so you would not be able to "stream" something to them.

Nothing to learn from Nazis? lol


approx. 100kb each, good luck

It appears that you have already given this a whole lot of thought.
My main suggestion would have been to get rid of lighting and shaders and you only need 1 texture instead of 4, but you had that covered already.
The only other thought on that is to reduce those sizes to as small as possible (keeping the power of two).
That means losing a lot of detail in the textures, but on the mobile devices, that should not matter unless you are zooming in close to the objects.

Everything you have considered here is doable, but it will be a lot of work.

I have used a lot of FPSC model in AppGameKit and I have just modified them as needed for only the ones I am using at that time.
Over time, I may get close to having a lot of them done, but doing them all without knowing if I will ever use all of them seems too time costly.
However, no sense in each of us doing them all independently when a pack could be organized, so this is a good idea.
It is surprising that TGC has not converted the FPSC assets for AppGameKit packs, but as we know it is a lot of work.
I am also surprised that the main website www.thegamecreators.com does not link to the www.tgcstore.net to offer the assets to those web surfers.

@Conjured Entertainment

My next step is, to somehow implement BASIS compatibility into AppGameKit Tier 2, so we could benefit from that also in Tier 1, if The Game Creators would implement it in the main release
https://github.com/BinomialLLC/basis_universal

I also looked into the textures, I guess, most of them are not better than 512px by 512px, and for mobile, Raspberry Pi, the OUYA, and low end PCs that would be enough, I am trying to get all into one database, so that you could reconstruct a higher resolution out of the source if needed.

DDS DXT compression would be about 6:1 and with BASIS it could be about 20:1

uncompressed (512*512*4)/1024/1024 ~ 1 MB in memory and on disk.
For 1000 unique textures that would be about 1000 MB, if we only use the diffuse + shadow baked ones.

With a compression of 20:1 nearly like using JPEGs (not speaking of the transparent ones)
That are about 50 kBytes, or 50 MB for all unique textures, if they are about 512 x 512, but there are also a lot, that are only 256 x 256 or allready combined to 512 x 512, but have about 4 or more inside

The biggest problem are the animated characters. There is no easy way to convert them into smaller file sizes.
I can reduce the amount of characters, maybe to 10 or 20. But every character is about 6 MB. We can compress them to *.X compressed and they are about 2 MB in size and contain about 99 sec. of animation.
The only way, to reduce them more without losing geometry is, to have less keyframes and maybe less animations.

walking, talking, swimming, jumping, crouch, get hit, falling, sitting, running, fighting, standing, move an object, pull, push, open a door / box, use inventory ... maybe we have about 100 unique animations.
So if we are lucky, we could describe them with about onlay 5 keyframes instead of 25. That would be about a "compression" of 5:1, so we could get the characters down to 400 kByte instead of 2 MB.
Maybe some of the mobs or doors would only have a hand full of animations, and therefor would not be as large.

So all character would be about 5 MB in size with that technique.

So a big thing are the objects itself. There we have really look into doppelganger. E.g. floor and walls, are mostly the same geometry, but only have other textures. Also some of the characters are often only copies of eachother.
A box is nearly a cube. A container, a box of wood, a box of metal and so on, they are nearly the same geometry

And the other thing is, maybe we could reduce the complexity of the objects itself and at first have only one genre.
The 29 chairs e.g. are about 2300 kByte in size. But there are twins. I didn't delated the twins and compressed it to 7ZIP. The result is 380 kByte. So each chair is about 13.1 kByte.
If we would have 1000 or these, than we 13.1 MB.

50 MB textures
5 MB animated characters
14 MB compressed objects
~ 20 MB the program itself
rest for voices, other audio, levels



Also there are chairs withing that are about 514 kByte one of them, the second biggest is about 377 kByte.
I guess, here and there we would do some hand picking and say, that a chair is a chair.
The 5 highest are about 1.54 MB
the 5 lowest are about 19.1 (everyone about 4 kByte)

Only using 19 chairs, not the 5 highest and not the 5 lowest, we get about 255 kByte when compressed to 7ZIP.
The average is also about 13.4 kByte

I guess, every category has to get there choice.

Some plants, some furniture, some doors, some vehicles, some buildings. I guess, bigger complex buildings and vehicles are bigger in size than a door or a wall.

Also for the plants the leafs have to be transparent. So there is potential for file size increasment.

The other thing could be, to compress the meshes with Draco, but that is another construction site.
https://github.com/google/draco

from what I read, there is a chance to get a compression of 95%. So 100% to 5%, that would be about 20:1
But they are using OBJ files as input. So mostly the OBJ files are tend to be bigger than *.X-files.

The conversion would be X -> OBJ -> Draco.
Some of the X-files, from 125 kByte e.g. would be abut 600 kByte as OBJ. So that could result into a maybe 90% of the OBJ, so that would be 60 kByte. So we could achieve 2:1 for compressed X-files with Draco.
But that is only theory at this moment. To use that, App Game Kit would need to have support also for Draco files. But also animations can compress with Draco.

- reduction in twins
- reduction in keyframes
- reduction in geometry
- reduction in values (less accurate digits)

so from some figures with about 30 MB, that could result in objects that are only about 300 kByte. Without loosing to much in detail. But a low-poly chair would not have that much of potential to be reduced.
Also some of the geometry could be translated to "normal-maps", but if we don't use them, will it work. Or does it work, let's say: 30 MB OBJ + 128 MB in texture uncompressed.
4K x 4K at 32Bit diffuse + normal -> to only 512 x 512 that would be a loss in quality, also a "compression" about 64:1
4096 / 512 = 8, so we reduce the quality here. But most of the FPSC Classic models maxout at 2K x 2K, a lot have 1K x 1K, and most have 512 x 512. So we would only reduce a few in quality.
But baking also geometry into the normals would be more advanced and would need maybe retropology and so on. So that is more a thing for a 3D artist.

So I guess, baking geometry into normal-maps is not possible. Also FPSC Classic models are mostly low-poly by todays standard. So a reduction in geometry is to complecated and would be not do much overall.

More about compression with Darco
https://medium.com/box-developer-blog/showdown-3d-model-compression-at-scale-draco-vs-open3dgc-c9618b7d64d8

OBJ

Compressed


Let's say, we look at the Soldier from Game Guru or the example in a lot of the App Game Kit one.
He is about 6 MB in filesize and has about 6K of faces.

To look into the table above, that would be like 10:1 from the bun_zipper.obj, which was reduced from 4.7 MB to 118 kByte. (39:1)
Our soldier would be about 470 kByte, because he has less faces. The reduction would be to 12 kByte. (asuming that it would be also 39:1)
But! That would be only for one frame. Our soldier has abot 99 sec. of Animation and 25 keyframes per sec. So he includes about more than 2475 keyframes.
If we can reduce the keyframes from 25 per sec. to 5, that would be 5:1.

so: 470/39*99/5 ~ 239 kByte.

Per full animated 6k of faces character. But that is all theory. Aaaa' Game Theory, ... making fun.

And here is, why we would need it in the first place.

512 is still too big for mobiles for anything viewed from any camera distance other than zoomed in on the model
256 is half scale but only one fourth the file size of the 512
With one fourth file size every step down (w/2,h/2) a lot of simple models with simple textures could even go 128x128 for 1/16 the file size of the 512 original.
If the end file size reduction is the ultimate goal, then the scaling down of textures can make a bigger difference than anything else other than the 4 to one reduction of texture file formats.

If the models are fairly low poly anyway, then conversion of the model files should not be necessary once the excess animations have been removed.
With many of the models being static, they have no animations and are small file size to start with.

The charts above are showing crazy face counts, and look to be very high detail models.

So, conclusion on suggestion being ...

1) select only low poly models to include in the pack

2) Reduce the multiple textures of each model to one that is 256x256 pixels or less ( 512 for characters or if 256 looks crappy)

With those two rules, the X/OBJ model formats with PNG textures should get you a long way without a lot of the other work.

High poly models should not even be considered for a project such as this.
Taking the extra steps you are taking will of course get a lot further, but the high poly models are still detrimental to the overall success of the primary goal.

@Conjured Entertainment

Maybe you are right and it is all nonsense and to much work. The idea behind that was, to have a good and easy starting point.
I have a Wacom Cintiq with Intel Integrated GPU and also some Acer Vivo Note 8 tablets. The Acer e.g. has only 2 GB system memory at all. And is about 8". And I also have an OUYA for TVs as bigger as 55" in FullHD. But the OUYA also has only about 1 GB system memory.
The idea is, to have a good balance between visual quality and GPU memory usage.

Also, I don't want to decide, if somebody makes a 3rd person game, a 2.5D platformer, where the camera is far away or a FPS, where you could go very close to the textured wall.

I know, there is not one solution, that fixes all the problems.

The starting motivation for me was, that Game Guru runs very slow with its terrain editor and the models load slow and the performance in the editor overall was not great. Also on my workstation with an i7 and about 18 GByte of RAM and a decent GTX 770 GPU.

The idea is, to be able to create some levels on the go, on lower spec machines and also in App Game Kit for Android in the mobile App. There are missing assets.
The next step would be, to create a little world-building tool. Easy like Minecraft. And if somebody wants, he/she could also implement some more with App Game Kit source on the PC. But a prototype could be build with some easy to understand tools.

Also Unreal Engine and Unity need a ton of space and installing the Visual Studio and so on is also a little bit of a pain.

The 100 MB restriction is not only for lower bandwith, or smaller USB thumbdrives, or to fit on low spec Android devices, but also because of some restrictions of the Google Playstore. And with 100 MB in one package, I guess, that could be a thing, we all could use.
No need for complecated asset dependencies or downloading every single source with gigabytes of assets, to test a specific problem or so.

A universal library, where we all would find something for our next prototype.

Today I saw the HumbleBundle
https://www.humblebundle.com/software/unity-2019-bundle

And read this
https://forum.unity.com/threads/snaps-prototyping-art-and-art-hd.746459/

There some guy says, that the assets about 1 GByte, but he thinks, that it would be possible to do them also in under 50 MB.

So that is also my point. I guess, having great assets on the one hand is great, but if they are so large, that only professional 3D artists can handle them correctly, they also could create there own.

And since App Game Kit with its Tier 1 Basic and easy to use language, editor and the support for Raspberry Pi, aims more or less the lower spec hardware, I guess, it would be also a big step in the right direction, to have good, but small assets.
Unreal and Unity don't do very well with there big and to large assets. For most games they are to heavy. I tried out the Unity tutorial projects and they are also to big for a quick start. And I have a i7 with about 18 GB RAM. But I would like to be able to develop 3D games also on a netbook or Raspberry Pi.

Also most of the shaders and lighting and so on, is to complecated. So most of the games still look kind the same, because "everybody" uses the same standard lights.

I guess, not every game wants to be a movie and not every asset has to be in a quality to be used in a cinema production pipeline. Back when the N64 and the PS1 were a thing, 3D with "lowpoly" was also able to tell a story.

as i understand it, the goal is to create a mobile-friendly level editor with "tons" of assets to choose from?

some thoughts:

i like the idea of generating thumbnails for everything, especially animated objects (that i wouldn't ever load into the editor - that's what the thumbnails are for ).

we're "placing" things, assigning characteristics, stats, etc, right? we don't need animations for that. IE, leave that for a level "previewer" which would only load what's necessary/what we tell it to via the data we provide to it/level files.

from within the editor, we could keep track of "actual" file size/storage, memory usage, even (general) polycount, etc, to monitor such things (and maybe even apply some optimization, there).

for non-animated stuff, i'd build (or, could (probably) "generate" a lot of them in-house (or out, using optimization tools)) the most-basic versions of whatever the objects and textures are to be in the game. ie, way-smaller (single) textures and the most-primitive objects necessary to properly represent the "actual" or "end product" objects.

IE, just whatever collision characteristics (maybe even MORE basic than that as long as you achieve what you're "building" - the level).

same for terrain, sound, etc. IE, the idea for such an editor is to simply place things, assigns characteristics, etc, then the previewer (or actual game) does the rest.

you could, perhaps, include the option to pull the real assets into the editor for the specific area that you're working on to add/tweak lighting, for example, then "offload" it to return to "lightweight" mode.

finally, FPSC and GameGuru, and, escpecially the MEDIA used there, were built for PCs. in the end, none of the media was never intended for mobile platforms. so, if we're to use it (the media) for something "elaborate" like a level editor, it should be made "mobile-friendly".

as you said, a lot of "doppleganger" stuff is in there, and the files are bloated because (most) PCs have the horsepower to deal with it. to achieve what you're after (an editor), that's what i would (primarily) attack, along with the above.

disclaimer: i've no real experience building a FPSC-type program. the above is "theory" and intended to provoke thought

Yes, that is the goal... making the FPSC assets mobile friendly.

I like the idea of loading the original asset in a tool that would allow the user to make the adjustments desired before exporting 'mobile friendly'.
That would definitely suit all needs and tastes, and would allow for conversion as needed.

However, if a simple tool could be developed to take the assets to the smallest possibly file size while maintaining an acceptable end result of the visual detail, then why not have TGC do the conversion and resell/redistribute the pack for mobile development?

For people who want the best image with the smallest size, then a repack would be effortless for the user.
However, determining 'best' level of detail and size is subjective and many users want full control.
So, the tool to do a customized conversion for a single object could be used by TGC and other users.
IMO, the tool is what TGC should be developing/selling rather than doing a repack, because it would benefit everyone, even those outside of the community with other 3D assets that are not yet 'mobile friendly'.
Even doing a repack, they would have to develop the tool for in-house use to ease the process for all of the model packs, so why not just stop there and let the users customize serving all users not just the ones wanting the smallest file size.

Best wishes for whoever decides to make such a tool first.
I can only chime in with opinions on this one instead of offering any real help, because I am still working on a 2D skeletal animation tool right now.
This tool could be simple because reduction will require 4 textures to 1, so that doesn't need to be an option.
Just letting the user determine the size of the single texture would make the biggest difference in file size and detail.
So, that would be all you need to focus on to start with to get something cranking our acceptable detail with small files.
You could KISS (keep it simple stupid) and still get nice results that you can add tool features/options as you go.
Even if you do not reach goal expectation on full optimization at first, you could still get drastic improvements with the basics.

since the Search-function is a "mess" here. I don't even find my own postings and threads. So I tried to find all the older related threads and postings to that topic.
I thought, that I somewhere posted some source code, but couldn't find it. So maybe I never did.

Here are the links:

in no particular order (ranging from 2016 - 2019):


AppGameKit Classic Chat / How do I get the Material from the FBX or GLTF / GLB or OBJ+Mtl or DAE?
https://forum.thegamecreators.com/thread/223366

AppGameKit Studio Chat / Is Appgamekit Going to Get a 3D scene editor?
https://forum.thegamecreators.com/thread/224787?page=1

AppGameKit Classic Chat / Community Animation Commands (3D) Voice, Movement, Path ..
https://forum.thegamecreators.com/thread/222129

AppGameKit Classic Chat / Classic remake game Jam Entries
https://forum.thegamecreators.com/thread/224454

AppGameKit Studio Chat / AppGameKit Studio Combine with GameGuru
https://forum.thegamecreators.com/thread/224419

AppGameKit Classic Chat / Why we need texture compression (e.g. ASTC) and Mesh-Merging
https://forum.thegamecreators.com/thread/223023

AppGameKit Classic Chat / Texture Compression Community Project
https://forum.thegamecreators.com/thread/220195

AppGameKit Classic Chat / 3D objects from asset store on TGC.COM in AppGameKit C/S
https://forum.thegamecreators.com/thread/224635

FPSC Classic Models and Media / FPSC Classic Assets for use in Game Guru (Feb-2017)
https://forum.thegamecreators.com/thread/218854

FPSC Classic Models and Media / Raw-Textures? TIFF, PNG? From FPSC Classic OpenSource? (Xaby: Nov-2016, Last: bossisly)
https://forum.thegamecreators.com/thread/218222

AppGameKit Classic Chat / The Future of AppGameKit?
https://forum.thegamecreators.com/thread/223328

AppGameKit Classic Chat / Low Poly and Light inspiration and community ideas
https://forum.thegamecreators.com/thread/222817

AppGameKit Classic Chat / Best way for transparent JPEG
https://forum.thegamecreators.com/thread/223757

So what I can offer is AppGameKit Tier 1 Basic "tool" which loads every model with its texture makes a "screenshot" and saves it as a bigger "thumbnail". This tool don't understands every kind of segments or *.fpe, and has hardcoded some broken *.x files
I also can offer a tool written in PureBasic, because AppGameKit does not have nice nativly GUI gadgets. This tool can load the "thumbnails" from the first tool and finds the models and can make a list out of them and generate a combined texture map.

This "AGK Thumbnail Maker" needs PNG / JPEGs before it can handle the textures. That is the biggest problem. *.DDS files have to be converted before with IrfanView, XnConvert or something like that.
The conversion of the texture-data takes some time. Also loading PNGs into AppGameKit takes time and saving PNGs also. So for that these tools are not optimised in any way.

Also I don't use AntiTwin or something like that. The idea is, that there would be the following easy steps:

- downloading all Assets from GitHub
- using only ONE tool
- having a bunch of texture atlases (like 10 or so) with all textures combined and having a ZIP-like-file where all models are packed in

I also figured out, that using the MeshMemblock-functions to load and save meshes from memblocks into files could make files smaller.
I also worte a tool in PureBasic, where the tool looks on the pixels, if there is transparency and if not, it would store the texture as JPEG, and if there is transparency, it would store it as PNG.

At the moment the idea is, to sort the assets by eye and flag them as "good" or so. But my tools don't have that yet. We are talking about 8000 3D objects, and the biggest problem was, that I couldn't decide from the 64 x 64 pixel thumbnail, if they are nice or not.
The next problem was, that I would have to store also the path of the file, because e.g. "Chair.X" in one path is another chair than in another path, maybe. So I also would have to implement checksums. But here is the next problem.

X-Files could contain there linked texture. So let's say we have a chair with texture1 and texture2. But chair1 is the same geometry like chair2, so we could say, we only need one of them.
But I could checksum it, because in the chair1-X-file is written down texture1 and in chair2-X-file is written down texture2. So my checksum would be differ.

I maybe would need to load both chairs into memblocks and compare them.

The endresult should be something like that:

Model-ID: 1000: Chair1 + texture1
Model-ID: 1001: Chair1 + texture2

And we would save the space of chair2

Another problem are combined textures. Sometimes walls and weapons and so on are on one texture for seperate objects.
So I also would need that the other way around.

Model-ID: 2000: Chair1 + texture1
Model-ID: 2001: Chair2 + texture1

so for that, a relational database would be great.

And we have a third "problem"

the FPE-files. Sometimes they are nearly identical, but maybe a prop is static or has other health-data. So maybe a database also would need to have something like most of the needed FPE-data as well.

The idea is, to load all "1000" models into memory and only refer to instances when having a placement editor or in game. But maybe also 1000 invisible models are to heavy for some platforms.
Also the 10 x 4K x 4K textures would require about 640 MB in memory for all assets. So maybe that is also not a good solution. But it would be possible to have them later only in 2K x 2K and so they would only be 160 MB, and could run on lower end hardware.
Or, and that would be a thought, only creating a texture for a specific game out of these 1000 models and textures.
Maybe a little game only required 150 textures and so it only would need maybe 1 combined texture.

The question here would be, if all 1000 models and textures would get a unique ID like an URL, so that we would benefit from having these 1000 models and textures on our computers and could reference in our source code to them.

Like MIDI for music.

I thought the procedural game .kkrieger might fit in here.
It's from 2004 and only 96KB in size.

@janbo

yes. So, how do we get AppGameKit to 96kByte with all Assets?

I know, the Deme Scene stuff is very much all about optimising filesize. I hope, that we could find a mittle way, between the artist and the software compressor engineer.

So, Godot now has BASIS Universal texture compression support.



https://godotengine.org/article/vulkan-progress-report-4

They talk about 75% smaller texture size. Don't know, against what they test it, but 75% would mean 4:1 in compression against uncompressed files and uncompressed memory usage.

So I hope, we could implement that also in App Game Kit.

... another thing could be the ORM for PBR. https://www.khronos.org/blog/art-pipeline-for-gltf
but I guess, not very much for saving on texture data in the first place. But maybe that could reduce texture count from about 6 to only 4.