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