16:11:36 <prock> #startmeeting 16:11:36 <fifer> Meeting started Sun Jan 9 16:11:36 2011 UTC. The chair is prock. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:11:36 <fifer> Useful Commands: #action #agreed #help #info #idea #link #topic. 16:11:48 <prock> :D 16:12:01 <vtchill> ok cool meeting officially started 16:12:01 <prock> cant believe I can still remember those commands 16:12:45 <prock> did you have a chance to review the structure of the pools and resource management in FIFE? 16:13:18 <vtchill> i looked over them a bit, but my understanding is probably lacking some 16:13:57 <prock> yeah I gotta refresh myself as well... I should have did that before the meeting I suppose 16:14:10 <prock> I'm going to grab some coffee.. then start looking at the doxygen docs 16:14:12 <vtchill> i am bringing up the code as well 16:14:26 <prock> lets discuss anything that comes to mind 16:15:22 <prock> as we look through it.. get as much down in the irc log as possible. we can go through after and see what we can come up with 16:16:22 <prock> I have some notes on my talk page as well.. http://wiki.fifengine.net/User_talk:Prock 16:17:01 <prock> also this is the official proposal page for the resource management stuff.. nothing much there yet. http://wiki.fifengine.net/Proposal:Resource_Memory_Management 16:19:56 <prock> Okay so a few things I want to mention... from the current pool system. I dont like the name "pool" and would prefer "ResourceManager"... "ImageManager", "SoundClipManager"... etc etc 16:20:08 <prock> but thats not a big deal... 16:20:17 <vtchill> i think manager is a better description 16:20:47 <prock> the other is the AnimationPool... To me animations should be managed within an "ObjectPool" or "ObjectManager" 16:21:07 <vtchill> joined with my other pc as well 16:21:10 <prock> k 16:21:27 <prock> An animation is part of an Object 16:21:34 <prock> a FIFE Object that is 16:21:45 <vtchill> what does an animation pool really provide? 16:21:53 <vtchill> isn't an animation just a sequence of images? 16:22:05 <prock> am I right? Im just assuming that Object -> animation is 1 to 1 16:22:44 <prock> let me look at animation pool to be sure 16:23:38 <prock> yup.. only holds animations which is just "key frame" data 16:26:29 <vtchill> is fifeclass properly used at the moment/ 16:26:44 <vtchill> i see some calls to addRef in the code, but not as many as i would expect 16:26:55 <prock> lol.. thats another problem I was looking at 16:27:04 <vtchill> although i do see some calls to addRef in the swig wrapper code 16:27:26 <prock> I dont see anything really using that except ResourcePtr 16:29:01 <prock> not too sure about the swig wrapper stuff 16:29:36 <vtchill> in the current fife model i guess i would expect: object holds animations and instances of those objects share and use the animations 16:29:49 <vtchill> but i am still not sure how an animation pool fits in the idea 16:30:57 <prock> yeah.. to me it would be ideal to use an ObjectManager that would manage all the Object data 16:31:05 <prock> which includes animations 16:31:22 <prock> the Images could still be stored in the ImagePool/Manager 16:31:48 <vtchill> yea they should still be stored there 16:32:09 <prock> currently FIFE::Model stores all the models and hands them out when requested. 16:36:27 <vtchill> so i say we try and start with something simple: the shared resources i can see within the engine are images, sounds, textures, fonts (which are probably really just images and textures), 16:37:01 <prock> images and textures are teh same? 16:37:12 <vtchill> no not the same 16:38:21 <vtchill> the image is the actual bytes from the image file on disk, the texture is the image data along with the primitives information given to the renderer 16:39:41 <prock> okay 16:39:50 <prock> but I dont think we really use the texture idea in fife atm 16:40:13 <vtchill> we sort of do, but not fully you are right 16:41:39 <prock> so texture would be kindof like the metadata for an Image 16:41:47 <prock> like material maybe? 16:41:49 <vtchill> if we keep it simple each manager can simply be an interface that basically provides: create, get, remove, removeAll, Add (this is if users want to add their own, may not be necessary at first) 16:42:36 <prock> sounds good. In the future we can add more detailed functionality 16:43:02 <prock> like memory quotas.. auto releasing of resources not in use for a long time.. etc etc 16:43:19 <vtchill> yea all that is extra functionality that can be added later 16:43:26 <prock> for some good ideas on those features check out ogre3d 16:43:56 <prock> I would also like to be able to set some manager properties as to when to load the resource 16:44:17 <prock> either right now.. or after it's requested for the first time 16:44:50 <prock> like my shooter demo example.. I'd like all resources loaded up front.. and not on the fly as it affects framerates 16:44:57 <vtchill> well the client is free to call create whenever they want wouldn't that give them the power to do that? 16:45:16 <prock> not sure how to do that at the moment with animations 16:45:47 <vtchill> you would preload all images (using create) that you will use and then during runtime the animation will just pull the images from the manager 16:48:38 <prock> yeah.. but I think I would have to write my own loader right now to do that with current code 16:49:08 <vtchill> hehe was just thinking the same thing, maybe add a flag to map format for auto load? 16:49:24 <prock> yeah 16:49:32 <vtchill> specify an image or whole directory as auto load 16:49:53 <prock> sounds good 16:50:53 <vtchill> i have a hard time envisioning how the vfs fits into the mix with these managers since most of the data they are manager are coming from the disk 16:51:35 <prock> I feel the same way... the loaders are what interface with the VFS 16:51:50 <prock> you add loaders to the managers 16:53:06 <vtchill> maybe you add directories and archives to the vfs and then specify create('name_of_resource') to the manager and it uses the vfs behind the scenes to look up the resource 16:53:47 <prock> yup that sounds reasonable 16:54:20 <prock> right now you have to pass in a "location" 16:54:40 <vtchill> yea that concept is a little fuzzy to me 16:55:02 <prock> the location is basically a holder for the "filename" 16:55:07 <prock> alont with it's relative path 16:55:31 <prock> but there is some other uses of ResourceLocation as well.. like SubImageLocation 16:55:32 <prock> etc etc 16:55:55 <prock> which isnt actually a filename.. its a reference to an already loaded image and dimensions for the "subimage" 16:56:05 <vtchill> ah ok 16:56:10 <vtchill> kind of like a texture atlas 16:56:37 <prock> correct...but what happens is the loader would render the subimage on a new image and enter it into the image pool 16:56:51 <prock> we currently do not provide a loader that works with this 16:57:22 <prock> it's kindof a neat featuer though as you could have one large texture that holds many small textures 16:57:39 <vtchill_afk> btw quick and dirty shared pointer implementation that i believe works, although may not be fully bug free... http://fife.pastebin.com/zYMkZc30 16:57:40 <prock> useful for animations... 16:58:09 <vtchill> yea the large image holding smaller, i think their are better ways to handle this probably 16:59:10 <vtchill> automatically handles increasing/decreasing reference count 16:59:42 <prock> looks good... we could add it to FIFE if you want. any testing we should do on it to verify it's bug free? 17:00:44 <vtchill> some simple tests can be done without the whole engine like creating a couple objects copying them around and sharing and then delete the owners and make sure it goes down at the right time 17:01:10 <prock> k.. I'll fire up a few tests later today 17:01:16 <vtchill> also the interface doesn't follow fife's coding standard as it was written in the coding standard i'm most used to (the one from work) 17:01:25 <vtchill> like upper camel case for functions, etc. 17:01:39 <vtchill> and it needs proper comments as well 17:01:41 <prock> we will have to fix that :P 17:01:54 <prock> okay back to your image/texture idea 17:02:04 <vtchill> yea i always have to change all function names when committing to fife b/c i always write the other way 17:02:37 <prock> I can see how texture would be handy... it could hold texture coords on a image for a particular "texture" 17:03:05 <prock> so I could have 4 textures in one image 17:04:42 <prock> so objects would hold textures rather than images 17:04:52 <prock> Is that what you mean by "texture"? 17:05:50 <vtchill> well when i say texture i really mean the opengl texture along with its id and primitive type 17:06:11 <vtchill> and image to me means image file on disk (it may contain more than a single actual image in it) 17:07:10 <prock> okay gotcha 17:07:40 <prock> what I may be referring to is "Material" 17:08:37 <vtchill> so in the opengl since material is colors and shininess associated with a texture 17:10:37 <prock> right 17:11:12 <vtchill> the usual 3d idea is, load a mesh (just vertex definition really and normals perhaps), load image data, apply material properties and upload to opengl server then render 17:11:42 <vtchill> we dont really have a mesh, so its just load image data and create simple texture (basically 2d) and upload to opengl server 17:12:51 <prock> our mesh is "object" 17:13:15 <vtchill> yea thats probably the closest approximation we have to it 17:14:22 <prock> object should contain animations IMO... can 2 different objects have the same animation? 17:14:34 <prock> and we should get rid of the animationpool 17:15:11 <vtchill> i guess they could technically but that is why you are caching images so if objects share images you don't have to load the image twice 17:16:02 <prock> k 17:16:33 <prock> so if we were to define some requirements for 0.3.3 what would they be? 17:16:40 <prock> as an example: 17:16:48 <prock> 1) rename pools to managers 17:16:57 <prock> 2) get rid of animationpool 17:17:43 <prock> 3) test and implement SharedPtr 17:18:21 <prock> how did you feel about the "resourcelocation" stuff? 17:18:23 <vtchill> 4) remove fifeclass 17:19:06 <prock> remove? what about clients that use the fifeid? 17:19:10 <vtchill> i dont see a ton of usefulness, but maybe something similar 17:19:35 <vtchill> ahh sorry i guess i meant remove the resource counting part of it 17:20:08 <prock> k sounds good 17:20:50 <prock> fifeclass has to be looked at for sure 17:21:05 <prock> lots of classes derive from it and I doubt they need to 17:21:12 <prock> but thats another story 17:21:43 <prock> 5) add the ability to add a resource from memory (via RawDataPtr) 17:22:10 <prock> mainly for the generated images 17:22:25 <vtchill> how many are generating images? 17:22:33 <vtchill> just overlays? 17:22:39 <prock> UH uses it a lot 17:22:44 <prock> the color overlays.. and outlines 17:23:02 <prock> they are all non pooled... Zero uses alot also 17:23:31 <prock> apparently helios did a quick hack to allow adding those outlines to pools.. and they seen a drastic improvement in zeros performance when highlighting objects 17:25:01 <prock> because they make a lot of use of that function 17:25:27 <prock> oh.. another thing I forgot about. The text that has been rendered is also pooled 17:25:35 <prock> and it has a time to live 17:26:09 <vtchill> well time to be visible, it could certainly still live in memory without a problem 17:26:38 <prock> yeah... really the renderer should know when it's no longer needed and free the memory 17:27:01 <vtchill> i would leave it up to the client for most things 17:27:16 <vtchill> each project will be different 17:27:52 <vtchill> time to live can always be added in the future 17:28:06 <prock> I believe those pools are defined in Font itself 17:28:34 <prock> did we want to make a manager for that? or leave that as part of Font? 17:29:17 <prock> well.. something to think about 17:29:28 <prock> I think I have enough to go on now to begin work 17:30:06 <vtchill> thats a good question for fonts 17:30:57 <prock> perhaps that should remain as part of teh font for now 17:31:07 <prock> as fonts have to be looked at as well in teh future 17:31:56 <prock> but... I have to run for now. I'll start work on the above mentioned action items 17:32:01 <prock> in the next week or so 17:32:06 <vtchill> ok cool 17:32:22 <vtchill> just remember simple and easy interfaces for now so we can add more later 17:32:27 <prock> #endmeeting