Sorry your browser is not supported!

Dear Community,

some of you know that Bugsy and I are working on a larger project. It is in preproduction for a while now and we start all out in 2013.
I took a couple hours to dig deep into the entire memorycap issue and came to a variety of solutions. However, some of them are still theoretical...

...and I would like to hear the opinion of some more advanced and technically talented people than I. Especially people who know off the code behind FPSC and people who are more experienced 3D modelers.

First of all: I lowered the resolution of most elements. The game will have detailed and artsy aesthetics but poorer graphics. Its a given process in an FPSC game like this.
However: What if a couple of models use the same texture? Will the texture be loaded a couple times in the buildprocess and consume as much as multiple unique textures.

Lets say I have 5 Elements of wooden furniture. Having them all use the same texture rather than having a 5 different textures would lower the memorycap siginificantly, correct? Are there any issues if I have all the items in a level source from the same texture map?

Characters are often similar with variations. What if I have soldiers whou roughly wear the same uniform have source from the same texture. Lets say its a 2048*2048 texture that include the bodytexture they all use and a couple faces and detail objects that vary...would this decrease the memorycap more than having a half dozen 1024*1024 sized textures? Would it be problematic shaderwise if a couple different meshes use the same textures? It shouldnt be, I know...but I want to be absolutely sure!

Do polygons consume a lot of memory?

Does the memoryconsumption in 1.18 and 1.19/20 differ a lot?

Do animations consume memory. Lets say I have a character who is playing a "typing" animation in a loop but does have all other animations saved in the file...does this character consume more memory than if I convert it in an entitie that only has one animation.

Is it advisable in FPSC to have lower resoluted shader maps compared to its diffuse texture?

I would really like a definite answer to these questions before I get all over this project.

Every hint is welcome! Thank you!



-Wolf

well from what I know:
It would seem to me that using 1 texture for multiple objects would
be good, I believe it's only loaded once.

polygons do matter in the memory department

there is a great difference in memory since 1.19

when a model is loaded, all animation is loaded with it, less animation means less mem resources. (I think)

another big memory killer would be the scripting and calling other scripts from a script.

Maybe, wait for FPSC-R? Sorry this hasn't answered any of your questions.

I don't pretend to be advanced or technically savvy in this area, but, what I do know is that when the game is being compiled into a stand alone each level is compiled and saved. During this compilation data is being stored in virtual memory rather than to disk so that it will be faster.

What seems to take up the most memory is light mapping. When you see "Calculating Object Light" is where the memory hits it's max. Calculating object light is dependent upon two settings in the ini file.

lightmaptexsize=512
lightmapquality=5

The default values are shown. A lot of people worry about what they see even when they are testing a small level. There is a certain amount of memory that is taken up regardless of the size. However, the size of the level will effect if there is enough memory left in order to process the light mapping. I found that if you can keep the amount of memory used, by the time it gets to that part of the processing, to 1700-1750, you can even increase the texture size to 1024 and light map quality to 75.

Before I make the next comment I would say that v120 will be the best bet to use as there as been some changes made to make better usage of memory used. That said I believe if you use v120 that you will not have any issues with memory increasing as each level is built. It pretty much resets itself before each build. Older versions have had problems with not releasing some memory and adding to each consumption for each level.

That said, I would just take a level you have currently been toying with for your new game and just play around with the parameters of the above two settings.

As far as polygons, I have no idea how they effect memory usage but I don't think there is that much usage. Textures is important and as far as model making and such, again, I have no idea.

But, to reiterate what I had mentioned in the start. FPSC-R is going forward. I would suspect betas released in about six months and maybe an initial first release by the end of next year for Christmas.

You don't' have to commit any monies but if you want the betas, you will need to do so. Otherwise just wait for the official release. The memory cap will be handled much more efficiently in that version of FPSC.

I don't know if this answered any of your concerns. You already have experience in making a great game and have used light mapping very effectively.

Hi Wolf, you have the open Into the Dark files at hand, you can dig in there. The game is designed so that with the default dividetexturesize=2 and picking up all weapons, the max. memory usage in the last level is at 99% of the max. But even that resoltued in memory-related crashes. The patch lowers the memory usage by reducing some textures. So that goes straight to your first question:



It will load only once.



No, but keep those which share textures in the same folder. Just to be on the safge side.



Not THAT much. I tested a 14k poly giant terminal with a 2048*2048 texture vs a 5k reduced model with the same texture, it was around 7MB difference.



Yes, 30 - 90MB depending on the level. 1.20 gives me the best results.



Yes. All animations stored in the X files are loaded. Less animations, less memory usage. But it`s not that much we are talking about...



Definately not except for cloudy spec maps and illu maps. Lowered Normal maps give awful results.



This is true, but don`t forget that some memory-consuming stuff is carried from one level to another. Weapons, Scary Tinker assets e.t.c.

Even if the build process shows only 1750MB used, a player carrying many of those weapons and items will hit the RAM limit upon loading this level and crash it.

I knew some was carried over but I didn't know what was the worst offender. I tinker around a lot with Scary Tinker. Sorry, I had to do it. But I do love Scary Thinker stuff.

you are on the right track about the textures. 2048 takes too much of the memory 1024 is better for the best of both memory and graphics. but 512 will take less memory than 1024 texture. notice how pack 53 will hog all the memory. the maps are large but yes if they use the same texture it will take the same. i have also notice the lightmap is not as bad if set on the right number. there is really a 40 mb difference with and without lightmap. the more entities ans different type of segments you use the more memory is used.and that because of their texture use. we never had this problem because our level was never so complex. but now we use more entities to give our levels that complex look. 512 texture and lower will allow you to have a larger level and the lightmap set at 25 will allow this as well. characters take a great deal of this because their texture are 1024 and higher as well weapons textures. but 1024 is good as long the texture is compress in dds format using only 512KB of memory. tga format eat up the memory taking large amounts of it. why because compress with a larger memory taking the same dds file at 512KB and making it 300mb. this is why we lose so much memory. all I have said was tested out and not in theory. which will help me in fpscR.

but if you use the same character in a level you will be able to have as many of that same character as you want. with taking any extra memory. about weapons if you use the same weapons as the characters and the character the same weapons. this can prevent load crashes for the next level save more memory.small objects like paper using 256 maps can help. dds format ready models can help in so many way then one.using mip can help with rendering and performance but without mip can save a little memory to. there is so much to explain on this but i have told as much is needed to understand.

I haven't used FPSC in a while(waiting for Reloaded), but I'll try and give a more technical viewpoint on the memory issue.

Do polygons consume a lot of memory?

No. Polygons are represented by three 3D positions(vertices) and sometimes can be optimized depending on their structure(triangle list,triangle fan,triangle strip,etc). A 3D position is generally made up of 3 floats which are 4 bytes each. 12 bytes for a single 3D position and there at least 3 of these positions per triangle(36 bytes per triangle). A 15k poly model takes up about half a megabyte for the position data. Low-poly is better for realtime performance, but I think the issue with the lightmapping is probably awkward handling of mesh data(lots of copying or even hanging references) and the mathematical calculations performed. Even then, polygon data won't be the worst offender for memory. Color data from textures is the worst culprit( (512*512)pixels * 4 bytes per pixel = 1 MB), with 1 MB of memory taken up by a single 512x512 image.

Do animations consume memory. Lets say I have a character who is playing a "typing" animation in a loop but does have all other animations saved in the file...does this character consume more memory than if I convert it in an entitie that only has one animation.

Animations take up a lot of memory, as the keyframe information for each and every single bone at each keyframe has to be loaded into memory and as such the memory footprint explodes when keyframes are added. DBP also has a performance issue with lots of bones.


I think that the best way to save memory during the build process would be to keep large textures at a minimum on static geometry, and also try to use animations as sparingly as possible.

Hey Wolf, how u been.
Im keen to jump in here and have a go at remembering certain things I was working around and or solutions.
Above comments are a greta insight and well put, texture size and complex model animations i.e. AI models are one of the main causes thats for sure in game run time rather than a build issue. However before I go any further I have a couple of questions first.


What is the big problem your trying to overcome?

Memory cap on final build?

lag - framerate drop on a single level?
i.e. general slow down with more assets added. or coming to a hault with random lock down in frame rate.

Being able to have more than a few levels in the final compile?


If I can think of more I will add, however if you can add your thoughts more in detail of the hurdle you both may be having a problem with or thinking may arise let us know.

Defy.

@Flatlander:

I am! And isn't it promised to be backwards compatible?
To be honest, while FPSCreator Reloaded is an obvious elephant in the room whenever I overlook my more serious projects (one day I'll release one...I just know it!) but its also still pretty theoretical for me. To specify: I don't know wether or not Fpscreator Reloaded will be all that has been promised so Bugsy and I are doing the prologue in the old Fpscreator. Fpscreator Loaded.



Thats fine! I have a perfect solution for that already but had to promise to keep it below the radar. I didn't follow recent development though but I think its integrated in 1.20 already but don't know for sure.



That is very helpful! Thanks Flatlander.



Thank you!

@MichaelX:

True! However, these are really High-end texture sizes. If you know a little about aesthetics and basic texturing I would suggest to use 512*512 as a default... maybe even lower if possible. For the game I work on with Bugsy I even have some props using 128*128 sized textures. Its a lot about how you use it. I'm aware thats a tough sacrifice to make in 2012, the age of high definition gaming and next gen engines approachable for everyone...we just have to remember that we are not working in one and we desire to create an athmospheric game and can't afford to sacrifice too many detail props.
My point is that your post felt alot like you use 1024*1024 textures as a default and I think it might be good idea not to

@Dar13:

That clears up a lot! Thank you

@Crazy Ivan: Thanks for the reply! It was short and informative However:



If you use them to give polished tiles a little depht you get good results. BUT the normalmap needs to have only the tiling present. Any details such as little cracks etc. will produce ugly pixel artifacts (naturally). I use 128*128 shadermaps in our game on a variety of props. So far I got surprisingly acceptable results.
(maybe it gives you some idea for into the ...ice. You never know. I did however attach a screenshot of some tiled textures with ultra lowresolution shadermaps to this post)



I figured! Thats why I had in mind to remove the weapons occasionally between assignments. That way there are always only 3 to 4 weapons to load.



... thats new information too. Its so much fun making these games isn't it?

@Defy:
Still alive and swingin'



The ridiculous content limitations per level that do not allow you to create level that last a certain amount of time even if you know how to solve it exactly. Having more models, props, sounds etc. in the game. Making a game thats a legit shooter and not some claustrophobic puzzle-horror-game where you have to look for some key in 4 barely lit rooms just to unlock the next loading screen.



I don't mind an occasional lagspike... and I'm pretty good at partitioning levels and spawning enemies at the right time to prevent that from happening. so no... no complaints there.



I can build them one by one and string the together later, thats not that big of a problem. Any insight would be appreciated.


* * * * * * * * * * * * * * *

Recent findings:

Low res texturing and having multiple assets source from a single texture work well and give splendid results.
Low res shader maps CAN be used but nor for everything. Specular maps can be very lowe res but need to be smooth and clowdy, otherwise the reflections are ugly pixels. being subtile is key here.
Characters sourcing from a single texture map is great but a lot of work to adjust the props.
Large, High poly objects tend to ignore lightmapping and cause problems collisionwise.
Collisionmodels have a strong impact on the framerate and you can boost it with simplified collisions. Most objects actually work best with boxcollisions. Really! I do however not know if it impacts the memory used... so here are some new questions:

Do the collisionsettings (polygonal, spherical, boxic...etc.) affect the memory used?
If I have a weapon as a static item, does FPSC sitll load in the entire gun?
Does FPSC use all DirectX files flawlessly no matter the conversion? Can it be a compressed file?
Do really low res textures get loaded flawlessly? Lets say I use some wires that are red and very small, would a 1*1 resoluted texture cause any unforseen problems?

Thanks! You guys have been great so far.



-Wolf

Going to sit back and have a good read and go through some old notes I was able to save, it's been awhile.
I'll let u know if I come up with anything.

Greetings Wolf, here are some of my findings; some echo others.
*Keeping animation to a minimum is definitely good. I'm personally setting up all my characters with only the animations needed. I used this method back in v1.03 and had some of the best results at the time when 30 fps was tops.
*Elimination of needless bones helps as well. If you seriously don't need a toe bone get rid of it, same with any other bone not being used in custom models. I used to be forced to add one bone in all my modeled buildings due to milkshape constraints;now I import into Fragmotion and export from there with no bone attached to the building and have tremendous results.The buildings in MP66 are somewhat high poly but I never dropped below 60 fps due to no bones and I use 1.19.( and that was with at least 4 talkers on the scene, and filling 2/3rds of the usable map space)
*I also use one texture for multiple models, so I think you are on the right track there.
hope that helps.

FPSC supports compressed X Models, i've gave it a try some time ago and it worked very well, the model ( a character ) was less bigger in size but i haven't noticed any performance loss or boost...

Back.
First Im going to drop in a convo I had back in 2009 with Magrand I found. Alot of members including u Wolf know this stuff, yet added for others for random reading...lol It may not apply however and Im not sure whats changed with recent engine updates. Though I would drop it in.
Hope u dont mind.


Mark says:
i got so much errors with virus, loading textures error initialising psyshics errors. Sometimes texture error and sometimes physic.
Defy says:
custom media? or re-edits of the sdk?, model packs?
Mark says:
custom
Defy says:
I noticed with the newer updates some media will test fine by itself, or with limited content. though when you add more detail.. a selected enitiy can trigger a error mainly due to the intensity of the object. faces, and or texture. Its a very strang glitch, here is some suggestions.
Once you get to a 0_0 error or something, it has alot to do with a enity, no matter where it is placed. I think a complex entity and/or texture can make the engine spin out. I had to scrap some I wanted, and run with more straight edge ones.
I had a hill entity, and even though I remade it a few different ways. static, dynamic, different texture. It seems the model itself, didnt work in a complex level design.
A glitch found 2 years ago, the editor thinks the model is still there when removed, like written into the code. and still makes the error, or lags out the level. I had one level near the end of completion. I added a few models. then a finishing threads errored appeared. because I made a save, tried one model at a time. test each go. Until I worked out which one played up. and scrapped the media. and replaced it with something else.
Mark says:
cool
Defy says:
Also the collision error, can be from a entity placed to close to another when light is added from random tests over time. Its trial and error. I found after light testing, more lights indoor can be faster loading, than less lights outdoor. though if you have shaders, shadows present, lights are rendered on the directions hitting models and back and forth of segments. like arrows or something, not really sure.
A complex entity, works nice by itself, add heaps around it, and boom. something may tweak.


Ok onto Textures.
I will be droping in various content here from other sources, however I will add links.








http://forum.thegamecreators.com/?m=forum_view&t=114462&b=24





This next section is for Celestia, however it has some good info that may apply.


http://www.lns.cornell.edu/~seb/celestia/textures.html#1.0


http://udn.epicgames.com/Three/TextureSupportAndSettings.html
Go to this link for a great chart on memory size for DXT1 & DXT5


http://gamedev.stackexchange.com/questions/7927/why-would-you-use-textures-that-are-not-a-power-of-2
Above, Raven mentioned try not to access MipMapping.



http://blenderartists.org/forum/showthread.php?154090-DDS-Texture-compression-resources


http://en.wikipedia.org/wiki/S3_Texture_Compression
Article on DXT compression.
http://www.fsdeveloper.com/wiki/index.php?title=DXT_compression_explained
Another great read on compresion in DDS.


Alot of this may be pointless info for u, however I found it interesting enough to add just in case others wanted links etc.
Great posts from the 2 above me
Defy

Very interesting thoughts and links. I knew many of statements and opinions already, something was new to me.

Do the collisionsettings (polygonal, spherical, boxic...etc.) affect the memory used?
They affect the physics system, so it could use more memory in the generating physics section of the build. Otherwise collision models shouldn't adversely effect build memory.

If I have a weapon as a static item, does FPSC sitll load in the entire gun?
It will load it in as it would an entity, not as a weapon.

Does FPSC use all DirectX files flawlessly no matter the conversion? Can it be a compressed file?
As long as the DX files are formed properly, then yes they will use it properly as FPSC uses DBP's Load Object command which in turn uses the DirectX SDK command for loading DX meshes.

Do really low res textures get loaded flawlessly? Lets say I use some wires that are red and very small, would a 1*1 resoluted texture cause any unforseen problems?
Perhaps. DBP has a tendency to force textures into a power of 2. If you have any detail it'll be blurred.

Wolf i know this is a little off topic but when FPSC:R comes out you should total redo Euthanasia. One of the best FPSC games ive played.

@wolf no I dont try to use 1024 or go higher. I only meant that other model packs or custom pack I have gotten or bond1 characters or pack 53 use this high end textures for their models. I on the other hand will change or lower some models not all depending on size. but what you said to me I agree we are on the same page about that.your segment packs I have use 512 which is great but bond1 zombies use 1024 or 2048 and when you lower them it shows. so his models I pass as is. but the memory cap is not much of my problem anymore since I discover this. I only explain my understanding of why memory is being use up quickly. out of everyone here I do not plan the bring old maps to FpscR. it will be a fresh start for me.

Great posts above.

Just going to continue where I left off.




http://www.yougamers.com/articles/13801_video_ram_-_how_much_do_you_really_need-page2/

Texture files can require a large amount of memory -- potentially many megabytes each -- and a game may display dozens of them at once. Reading the textures from the hard drive, or even the system's memory, before processing each image would result in lag, so the graphics card must store active textures in its own memory.


Seen how collision has been mentioned, I'll add some points here also.

Rolfy post, its fpsc related and a good read.
http://forum.thegamecreators.com/?m=forum_view&t=197834&b=21



http://udn.epicgames.com/Two/CollisionTutorial.html
UDK tut, however has some good info that address's collision.




From what Ive been reading, overlapping static objects with collision is not a great idea. I remember from playing some games, it was like a complete transparent wall was blocking my way when trying to get to a certain area (like computers against a wall, etc.) This may have something to do with what I mentioned above in another post with shaders.
It may just been the object placement too close to each other with overlapping collision and or both. Just an idea, I may be wrong.
It looks like Box would be best in terms of faster speed, however if the model is a statue with a arm, your not able to walk under it. Maybe some testing is at hand.

Also on the texture size, I keep reading a medium size is good. Such as 256x256 or 512x512, due to the downscale and up scale properties.
i.e. 256x256 can scale down to 128x128 and up scale to 512x512 for example. However Im not sure if or how upscaling works in fpsc.

One other thing I thought I might add was Trigger zones for AI.
I found adding triggers caused frame rate drops and/or Ai not responding when using too many compaired to 2 or 4, or none at all. Im not sure whats changed with recent updates/versions. However I was at a point where I wouldnt use them at all for AI, unless I had to.


Anyway I'll be back later. Great work guys, really good posts.


2 more good links and pictures on collision.
http://content.gpwiki.org/index.php/Polygon_Collision

http://rbwhitaker.wikidot.com/collision-detection