From K-3D
To Attend
- Meeting Time: 20071117 1700 UTC
- Timezone Information: www.timeanddate.com
- Meeting Protocol: XMPP (Jabber) Conference
- Meeting Location: k-3d@conference.jabber.org
Agenda
- Action Item Followup
- Schedule Bug Day
- Video Next Steps
- Proposal: Make presentations at local LUGs, video clubs, etc.
- Develop some standard presentations?
Action Items
- Create Video Tutorials page - Joaquin
- Everyone create a short "feature" video.
Discussion
(10:52:48) joaduo: Tim we where asking ourselfs if you know its 17.16?
(10:52:53) bart: Tim, do you know you are either 45 minutes late, or we all got the time wrong? ;)
(10:52:53) joaduo: 17.46
(10:52:55) joaduo: sorry
(10:53:23) Tim Shead: Could be me, I suppose.
(10:54:07) Tim Shead: Yes, that would be me.
(10:54:24) joaduo: :)
(10:54:35) bart: About the meeting date/time...
(10:54:36) Tim Shead: So ... where are we at?
(10:54:52) bart: would it be possible to do it on sunday, same time?
(10:54:59) Tim Shead: It?
(10:55:04) bart: the meeting
(10:55:26) joaduo: http://k-3d.org/wiki/User:JoaquinDuo/Main_Page_Proposal
(10:55:45) Tim Shead: Fine by me - you mean permanently?
(10:55:45) joaduo: bart: you mean this meetings, not about bug-days?
(10:56:09) bart: Yes, talking about this meeting
(10:56:16) Tim Shead: Any objections?
(10:56:33) bart: This is the second saterday in a row that I'm not at home for the meeting
(10:56:43) joaduo: could be on sunday, sometimes i have more activities, but lets try...
(10:56:50) joaduo: we need to ask joe
(10:56:51) Tim Shead: Sunday it is.
(10:57:01) joaduo: Anders Dahnielson: you?
(10:57:15) Anders Dahnielson: Sunday is ok for me
(10:57:16) bart left the room.
(10:57:33) Anders Dahnielson left the room.
(10:57:33) Tim Shead: So, did you guys cover any part of the agenda?
(10:57:37) joaduo: ok, bart decided is on sunday...
(10:57:51) joaduo: not at all
(10:58:06) Tim Shead: Well, let's wait and see if they come back ;)
(10:58:09) joaduo: i was showing those changes in the news section
(10:58:35) joaduo: Anders is from europe too isnt it?
(10:58:45) Tim Shead: I believe so.
(10:59:21) joaduo: i was thinking about trying to send a mail regularly on the announce ML, maybe every two weeks?
(10:59:44) joaduo: and update the main page news section also in that time base
(10:59:53) joaduo: probably with the same time base
(11:00:02) Tim Shead: Sounds like a winner.
(11:00:14) joaduo: probably with the same type of news* i meant
(11:00:30) bart [barche@gmail.com/Kopete] entered the room.
(11:00:40) joaduo: ok
(11:00:46) Tim Shead: Thought you switched to Sundays right away, Bart :)
(11:00:47) joaduo: we wait for anders?
(11:01:00) Tim Shead: Yeah, let's give him a few minutes.
(11:01:02) bart: sorry, client problem :)
(11:01:16) bart: kopetesometimes stops showing my own messages
(11:02:02) Tim Shead: So, I have switched next week's meeting to Sunday the 25th.
(11:02:14) joaduo: tim have you checked the script?
(11:02:19) bart: OK, great, thanks!
(11:02:30) Tim Shead: joaduo: not yet.
(11:02:47) Tim Shead: Actually, let's get going.
(11:03:09) Tim Shead: I posted new binaries for testing, you can see links in today's agenda.
(11:03:21) Tim Shead: This incorporates Bart's fix for the Win32 issues.
(11:03:24) joaduo: yes, i am installing on xp
(11:03:43) Tim Shead: Once I hear that they're working, I'll do the "real" release.
(11:03:52) bart: OK, I'll test them
(11:04:00) bart: getting nowhere on the vista issue, though
(11:04:28) joaduo: uhm, i think we could think on vista for next release?
(11:04:33) bart: I've googled a bit, mostly, but can't find any reference to anyone having problems with queue_draw in gtkmm... maybe it's something else after all
(11:04:43) Tim Shead: Not gonna wait on Vista.
(11:05:01) bart: I guess the power users are still on XP, anyway :)
(11:05:17) Tim Shead: I committed the first round of changes for per-render-engine node visibility.
(11:05:18) joaduo: bart: have you tested other 3d soft?
(11:05:38) bart: joa, not opengl, no... but Guild Wars runs fine :)
(11:05:49) Tim Shead: It is working for the GraphViz render engine - there is a "Node Visibility" property with UI for picking nodes.
(11:06:04) joaduo: ok
(11:06:16) bart: Tim, I saw the commit, haven't tested it yet, though
(11:06:29) joaduo: niether do i
(11:06:32) bart: So in the future, the mesh address will be constant, right?
(11:06:36) joaduo: neither*
(11:06:46) Tim Shead: I began with GraphViz because it's an interesting special-case - it "renders" any type of node, so there isn't any filtering at the moment.
(11:07:13) Tim Shead: It'll be extremely useful for generating diagrams though - you can turn bits-and-pieces of the pipeline on-and-off to suit.
(11:07:54) bart: ah, yes... could avoid some clutter
(11:08:02) Tim Shead: Mesh-address-constant: yes.
(11:08:44) bart: How will this be done? Replace all .reset(0, Hint) calls, or handle it in the property once and for all?
(11:09:20) Tim Shead: Yes.
(11:09:54) Tim Shead: It will be a combination of both.
(11:10:09) Tim Shead: From the perspective of a "hint consumer" though, don't overthink it ...
(11:10:25) Tim Shead: You will get hints that indicate that a mesh has been changed ...
(11:10:39) Tim Shead: Or you will get hints that indicate that a mesh has been destroyed ...
(11:10:49) Tim Shead: ... as long as you handle both, everything will just work.
(11:11:06) bart: OK, that is good. Having a constant address will simplify mesh_instance and the painters a lot
(11:12:04) Tim Shead: I emphasize that keeping a constant address is an implementation detail of an upstream node. If they don't maintain a constant address, everything must still work - it'll just be less efficient.
(11:12:32) bart: OK, that will just delete the mesh every time then
(11:12:38) Tim Shead: Again, from the perspective of a painter, there are meshes that appear, meshes that change, and meshes that go away.
(11:13:29) bart: OK, fair enough
(11:13:32) Tim Shead: Moving along the action items from last week, I've added the new k3d-announce ML, and updated the forums so we have a single "User" forum.
(11:13:52) joaduo: ok
(11:14:16) Tim Shead: Knock yourselves out :)
(11:14:30) Tim Shead: I will be adding the k3d-announce ML to the release checklist in the wiki.
(11:14:50) bart: OK, I just subscribed
(11:14:55) Tim Shead: BTW, I was sick last week, so I cranked all of this out at the last minute ...
(11:15:17) Tim Shead: The SoC 2008 starter page is in the wiki, start adding your project ideas now ...
(11:15:44) joaduo: don't worry
(11:16:06) bart: About SoC2008: we talked a bit about having an entrance test last week...
(11:16:45) bart: I think an example of such a test could be a "mirror" module, where you have to write a plugin that mirrors it's input around a plane
(11:16:57) bart: s/you/the student/
(11:17:47) joaduo: all right, we should have to give documentation on the data formats
(11:18:24) bart: We could leave the method of defining the mirror plane free, allowing students to show creativity and motivation. i.e. choosing a fixed "z = 0" solution is less effort than allowing input of 3 points or something
(11:18:45) Tim Shead: Right, I'm a little leery of calling it a "test", I think we night to strike the right balance so as not to insult talented people.
(11:19:29) Tim Shead: I think that requiring students to "submit a simple new K-3D plugin" would be a reasonable request.
(11:19:40) bart: ok
(11:19:43) joaduo: i agree
(11:19:54) Tim Shead: It's a little-more open-ended than doing a mesh problem.
(11:20:11) Tim Shead: Which I think is reasonable, since not every project is a mesh project.
(11:20:17) bart: OK, maybe we could cite it as an example to indicate the expectded level of complexity
(11:20:35) Tim Shead: Well, I see a chance to judge motivation.
(11:20:56) Tim Shead: If someone submits a sample plugin that's a copy of the plugin tutorial, that says something.
(11:21:30) bart: OK, I guess if you just submit k3d::log() << debug << "hello world" you can't expect much, as a student :)
(11:21:59) Tim Shead: We can refine the wording as we go - we would like a simple plugin that provides some useful new capability.
(11:22:12) bart: OK
(11:22:28) Tim Shead: But yes, if someone submits a hello world plugin, that speaks to their level of motivation.
(11:22:54) bart: As project idea, I had thought about NURBS modeling tools.
(11:23:06) Tim Shead: Sounds cool - write it up!
(11:23:21) bart: OK!
(11:23:54) Tim Shead: I cut-n-pasted the parallel processing to get the page started, but I need to rethink some of it.
(11:24:02) bart: OK
(11:24:05) joaduo: IK could be, and adding skinning features
(11:24:36) bart: I'll try to get some benchmarking in, to test what can be expected. On the old mesh-structure, memory bandwidth was the limiting factor
(11:24:37) joaduo: although, i think google is more attracted to new ideas, isn't it?
(11:25:47) Tim Shead: I don't think that there were any radically-new ideas in last year's projects.
(11:26:08) joaduo: tim, i have tested the pgp module, but couldnt make i work, should it?
(11:26:29) bart: The architecture tools seem like a good idea, too
(11:27:06) joaduo: well i guess pgp remesh is not a feature every 3d soft have
(11:27:15) joaduo: i mean new in that way...
(11:27:48) Tim Shead: My concern with the architecture stuff is that it is heavily UI-oriented. I don't think it's a realistic goal for SoC.
(11:28:26) Tim Shead: PGPRemesh works in some cases, but it's a good example of why we don't want projects that deliver one complex plugin next year.
(11:28:31) bart: hmm, ok... maybe we should clean it up a little then, make it less UI centric
(11:28:51) joaduo: tim, i guess we should have manipulators plugins, that would make things easier, isnt ti?
(11:28:53) joaduo: it*
(11:29:15) Tim Shead: Yes, that's a thought that has crossed my mind.
(11:29:31) Tim Shead: All of the current UI Tools should be plugins.
(11:30:13) joaduo: ok, tell me if i can help
(11:30:23) Tim Shead: Will-do!
(11:30:34) Tim Shead: I had "Schedule Bug Day" as the next item on the agenda.
(11:30:43) Tim Shead: Let's postpone that until we have more people.
(11:31:01) joaduo: ok
(11:31:28) Tim Shead: Next item was Video "Next Steps" ... now that we have a working video solution, we need some web work.
(11:31:54) Tim Shead: Joaquin, would you be interested in setting-up the video gallery?
(11:32:02) joaduo: ok, no problem
(11:32:16) joaduo: how do we call the article
(11:32:20) joaduo: Demo_Videos?
(11:32:27) joaduo: Tutorial_VIdeos?
(11:32:45) joaduo: or you want something outside the wiki?
(11:32:52) Tim Shead: Within the wiki
(11:33:05) bart: I think there coul be more than one
(11:33:25) bart: We should have a feature showcase with videos, as well
(11:33:27) Tim Shead: I would suggest "Video Tutorials", to reinforce the connection with "normal" K-3D tutorials.
(11:33:44) joaduo: ok
(11:34:00) bart: They could show short actions, like the graphviz plugin or interactive SDS manipulation, for example. 1 minute max.
(11:34:07) Tim Shead: The "Video Tutorials" page would link to the individual videos, one-per-page.
(11:34:09) Tim Shead: Agreed.
(11:34:38) Tim Shead: The one-video-per-page thing is important, otherwise you have a page full of players, each hitting the server all-at-once.
(11:34:56) joaduo: ok
(11:35:07) Tim Shead: There's a link to my video page, where you can see how to embed the video into the wiki.
(11:35:17) Tim Shead: There's only the one video at the moment, of course.
(11:35:20) joaduo: bart: i would suggest short and large videos, depending on the video creator
(11:35:30) Tim Shead: Yep.
(11:35:42) bart: Yes, long videos have a place too, i.e. as instruction to actual users
(11:35:42) joaduo: i saw the tests
(11:35:49) Tim Shead: We should think about what the next video should be.
(11:36:09) joaduo: we could make a video on how to install K-3D on linux
(11:36:36) bart: 3 hours of make scrolling the console ;)
(11:36:42) joaduo: haa
(11:36:45) joaduo: lol
(11:36:50) Tim Shead: I don't think that would work well in video - too many different distributions.
(11:37:58) joaduo: well... if anyone wants s/he could
(11:37:59) bart: OK, I suggest making some short feature showcases, then
(11:38:25) Tim Shead: Seems reasonable.
(11:39:25) joaduo: agreed
(11:39:40) joaduo: should we suggest topics right now?
(11:40:30) Tim Shead: I'm gonna say let's wrap it up for the day ... three people is a little light for a quorum.
(11:40:45) bart: Well, basic camera navigation, basic interactive tools, the SDS preview, the pipline visualization
(11:41:03) joaduo: rendering....
(11:41:12) joaduo: material edition
(11:41:16) bart: yep
(11:41:16) Tim Shead: Maybe a good goal should be for everyone to produce one video of their own.
(11:41:24) bart: ok
(11:41:25) joaduo: ok
(11:41:35) bart: I've already got everything instlled
(11:41:40) bart: One more thing:
(11:41:43) Tim Shead: I just bought a microphone.
(11:41:47) joaduo: bart: can you set SDS with one interation?
(11:42:12) bart: in the case of recordmydesktop, we should also provide the ogg. It's great quality, and not big
(11:42:18) bart: joaduo: yep
(11:42:55) joaduo: is useful for performance issues
(11:43:35) Tim Shead: Cool ... shall we wrap up?
(11:43:49) joaduo: ok
(11:43:52) bart: ok
(11:44:15) joaduo: well, next meeting we could talk about the website proposal
(11:44:19) Tim Shead: Great ... sorry for the confusion on time ... the next meeting will be at 1700UTC (for real) on Sunday, November 25th
(11:44:26) joaduo: we talk too little
(11:44:32) bart: I have one more suggestion I thought about today, but it doesn't have to be on the official agenda
(11:44:34) joaduo: talked* on the las meeting
(11:44:50) Tim Shead: What's that?
(11:45:08) joaduo: http://k-3d.org/wiki/User:JoaquinDuo/Website_modification_proposal
(11:45:29) bart: OK, let's talk about the website first
(11:46:09) joaduo: i was thinking we should wait for joe
(11:46:20) joaduo: although if you have any suggestion
(11:46:34) Tim Shead: Yeah, let's have more input for something that significant.
(11:46:44) bart: ok, just one, at first sight: we should have a "Features" section
(11:47:10) Tim Shead: I think there is one around somewhere, but it should clearly be more prominent.
(11:47:11) joaduo: under documentation?
(11:47:26) bart: No, as main item.
(11:47:51) bart: Under K3D Menu
(11:48:12) joaduo: ok...
(11:48:32) bart: It would be a page that showcases our most significant features using screenshots and video
(11:48:45) bart: As an attempt to pull in new users
(11:48:53) Tim Shead: Agreed.
(11:48:53) joaduo: could be an About item also
(11:49:34) bart: Anyway, Tim is right, the others could probably produce more and more valuable input next time :)
(11:50:04) bart: I had one small technical idea I wanted to talk about, since we're here anyway
(11:50:09) Tim Shead: So a general observation: talking about website organization seems like a really low-bandwidth way to work.
(11:50:35) Tim Shead: You guys (particularly Joaquin), should do mockups of what you have in mind - then the group has something concrete to look-at.
(11:51:02) joaduo: ok
(11:51:11) Tim Shead: Think of it as "staging" changes for approval before they go live.
(11:51:26) Tim Shead: Remember that you can use your user pages as a "namespace" and go wild.
(11:51:32) joaduo: what i was going to propose is to create the alternative article on the discussion pages
(11:51:34) Tim Shead: Joaquin is already doing this.
(11:51:58) joaduo: or on my namespace
(11:52:03) joaduo: :)
(11:52:18) Tim Shead: Better to put the content in the main article and leave the discussion page for discussions.
(11:52:32) Tim Shead: That's why I prefer the "staging" approach in your user area.
(11:53:15) Tim Shead: Bart, you were saying?
(11:53:33) bart: I had been thinking about measuring fps
(11:53:50) bart: Since we are going to modify hint processing, performance might be impacted
(11:54:07) bart: It would be good to have some formal performance benchmarks
(11:54:35) Tim Shead: You're thinking beyond the fps we already display?
(11:54:45) bart: So I suggest creating an ifps_counter interface, accessible from python
(11:55:03) bart: it would have methods like average_fps, max_fps, reset_fps, ...
(11:55:07) Tim Shead: Have you looked at the Pipeline profile panel?
(11:55:12) joaduo: would be useful for the regression test for example?
(11:55:36) bart: Yes, it would be similar I guess
(11:56:04) Tim Shead: Similar to k3d::ipipeline_profiler?
(11:56:19) bart: Hang on, gotta look at it :)
(11:56:55) bart: The problem with the profiler is that it only profiles methods that call it
(11:57:41) Tim Shead: That's the only way to know where the time is spent.
(11:57:53) bart: I would like something that can be controlled from python, i.e. call the reset method, do some manipulations, and display the statistics
(11:58:15) bart: Just as a verification, not as a tool to determine bottlenecks
(11:58:50) Tim Shead: That's exactly what ipipeline_profiler does.
(11:59:25) Tim Shead: If the callback interface is a problem, use the timer support in Python to get your fps.
(11:59:54) bart: The problem is that it times... Rotating an object in the viewport always takes approximately the same time, but it may happen at different framerates
(12:00:42) Tim Shead: If you're driving the display from a script, you can keep track of time at whatever granularity suits you.
(12:01:15) bart: OK, I'll experiment a little in python, then. Maybe I just don't know the existing methods well enough.
(12:01:34) Tim Shead: Okey dokey, I've got to get going ...
(12:01:43) Tim Shead: Thanks for sticking around, guys!
(12:01:49) bart: But the goal remains to get fraerate statistics, using a predefined test, so we can monitor performance evolution using the criterion the user values most
