The limitation is coder skill, not hardware. That .kkrieger example is 20 years old. It could make a Pentium 3 “generate an entire FPS game” from less than 100kb of coding instructions alone.
The question is "why don’t other people do it, then?" and the answer is “because having all those media resources as files makes the startup faster, memory usage down and is easier to modify and replace”
“because having all those media resources as files makes the startup faster, memory usage down and is easier to modify and replace”
None of that matters, because you can load them in the background/parallel wise, as needed, which is what the game already does today.
But all of that takes space on the hard drive, which brings me back to the point I keep making.
My original comment…
You’re not wrong, but also the space that they would need on your hard drive to make the game really non-repetitive visually would be out of this world (pardon the pun)
, and what I keep replying back to comment on, is specifically about visuals, and variety in the planets, the areas of the planets, and the star systems, and the aliens. 3D models and meshes.
What you been describing is not 3D models and meshes, which is what takes up the majority of the hard drive space.
So, can you describe for me how the hard drive space for 3D models and meshes would be?
What you been describing is not 3D models and meshes, which is what takes up the majority of the hard drive space.
My brother in christ, what the fuck do you think i’ve been describing then? I even linked an example of how the 3d model itself, the geometry, the mesh, occupies less disk space than the actual textures
For comparison, this Damaged Helmet in gltf format (which you can see on your browser here) has 15k triangles, a .bin file (the actual 3D geometry) of 545kb and roughly 3MB of textures - The Default_albedo.jpg is the “actual color” and it alone is larger than the .bin + .gltf, at 914kb.
What I see is that you don’t understand how procedural generation works. As is today, how do you think planetary terrain is generated? That it is all saved as a file that is read from your computer/PC? That you could load up a “planetXYZ.file” externally to edit it? That the terrain mesh is this huge file with all sorts of hills and plains that you could import/export and load in Blender?
My brother in christ, what the fuck do you think i’ve been describing then?
Algorithms that use the models/meshes/etc., and not the models/meshes data themselves. Algorithms take up allot less space on the hard drive.
What I see is that you don’t understand how procedural generation works.
I’m a computer programmer. I’ve written that kind of code before (gotta love some Perlin noise). /sigh
Also, you’re not quoting me on that part, but someone else. I didn’t make any mention about a ‘Damaged Helmet in gitf format’ (or anything else in that text you quoted).
As is today, how do you think planetary terrain is generated?
It mixes/matches models (that have meshes, etc.) like Lego pieces to assemble the landscapes/things. If you want more new/varied worlds, you need more models/meshes. The algorithms are not going to create them, its going to just assemble the ones that already exist as files on the hard drive.
Edit: Funny enough, I’m currently downloading the update, all 7.48GB of it. The whole game takes up 14.69GB on my hard disk. I’m going to bet most of the update is the new stations look/variety, and not the logic code for mix-and-matching ship parts.
The limitation is coder skill, not hardware. That .kkrieger example is 20 years old. It could make a Pentium 3 “generate an entire FPS game” from less than 100kb of coding instructions alone.
The question is "why don’t other people do it, then?" and the answer is “because having all those media resources as files makes the startup faster, memory usage down and is easier to modify and replace”
None of that matters, because you can load them in the background/parallel wise, as needed, which is what the game already does today.
But all of that takes space on the hard drive, which brings me back to the point I keep making.
My original comment…
, and what I keep replying back to comment on, is specifically about visuals, and variety in the planets, the areas of the planets, and the star systems, and the aliens. 3D models and meshes.
What you been describing is not 3D models and meshes, which is what takes up the majority of the hard drive space.
So, can you describe for me how the hard drive space for 3D models and meshes would be?
My brother in christ, what the fuck do you think i’ve been describing then? I even linked an example of how the 3d model itself, the geometry, the mesh, occupies less disk space than the actual textures
What I see is that you don’t understand how procedural generation works. As is today, how do you think planetary terrain is generated? That it is all saved as a file that is read from your computer/PC? That you could load up a “planetXYZ.file” externally to edit it? That the terrain mesh is this huge file with all sorts of hills and plains that you could import/export and load in Blender?
Algorithms that use the models/meshes/etc., and not the models/meshes data themselves. Algorithms take up allot less space on the hard drive.
I’m a computer programmer. I’ve written that kind of code before (gotta love some Perlin noise). /sigh
Also, you’re not quoting me on that part, but someone else. I didn’t make any mention about a ‘Damaged Helmet in gitf format’ (or anything else in that text you quoted).
It mixes/matches models (that have meshes, etc.) like Lego pieces to assemble the landscapes/things. If you want more new/varied worlds, you need more models/meshes. The algorithms are not going to create them, its going to just assemble the ones that already exist as files on the hard drive.
Edit: Funny enough, I’m currently downloading the update, all 7.48GB of it. The whole game takes up 14.69GB on my hard disk. I’m going to bet most of the update is the new stations look/variety, and not the logic code for mix-and-matching ship parts.
deleted by creator