| *** cgTobi has quit IRC | 00:16 |
| *** Aren has joined #aqsis | 02:19 |
| *** Aren has quit IRC | 03:30 |
| *** scorp007 has quit IRC | 03:52 |
| *** pgregory_ has joined #aqsis | 06:56 |
| *** pgregory has quit IRC | 06:58 |
| *** pgregory_ is now known as pgregory | 06:59 |
| *** pgregory_ has joined #aqsis | 06:59 |
| *** ChanServ sets mode: +o pgregory | 06:59 |
| pgregory | morning all | 06:59 |
| *** AlexK has joined #aqsis | 07:16 |
| *** Pseudonym has quit IRC | 07:21 |
| *** Anteru has joined #aqsis | 07:50 |
| Anteru | Morning | 07:50 |
| pgregory | morning Anteru | 07:50 |
| *** pgregory sets mode: +v Anteru | 07:50 |
| Anteru | morning paul | 07:50 |
| *** pgregory sets mode: +v AlexK | 07:51 |
| Anteru | People come rushing in ^ :) | 07:52 |
| *** scorp007 has joined #aqsis | 08:00 |
| Anteru | Morning scorp007 | 08:00 |
| scorp007 | hi | 08:02 |
| *** pgregory sets mode: +v scorp007 | 08:07 |
| Anteru | Do we have 4 applications now? | 08:09 |
| pgregory | 5 | 08:11 |
| scorp007 | Has google determined who is successful yet? | 08:11 |
| Anteru | w00t! | 08:11 |
| scorp007 | Since I assume the deadline has been reached? | 08:12 |
| Anteru | Yeah but I think they have time till the 4th march or something like that. | 08:12 |
| scorp007 | What were the 5? I know Multi-threading, ... what else? | 08:12 |
| Anteru | Ray-tracing, GPU, Flipbook, Multithreading, ... Parser? | 08:12 |
| scorp007 | Anteru, 4th March? Its the 26th now? | 08:12 |
| Anteru | ähh 4th april :P | 08:13 |
| Anteru | ehh ^ | 08:13 |
| scorp007 | So Google has till the 4th April to decide? | 08:13 |
| Anteru | Wanted to turn back time to have 24 days left for learning. | 08:13 |
| Anteru | If I understood it correctly, the students will be noticed till then whether they have been accepted. | 08:13 |
| scorp007 | you mean notified? | 08:14 |
| Anteru | err, yeah, notified | 08:14 |
| Anteru | Damn, what's going on today :) | 08:14 |
| scorp007 | ok, I somewhat understand now | 08:14 |
| Anteru | Seems this chinese remainder theorem makes me crazy ... | 08:14 |
| Anteru | Paul, what's the 5th? The RIB-Parser rewrite or something different? | 08:15 |
| pgregory | Anteru: MT, Animation Player, RT, RT, GPU | 08:16 |
| scorp007 | RT = RayTracing twice? | 08:16 |
| Anteru | Cool | 08:16 |
| pgregory | yep | 08:16 |
| Anteru | Then it might work | 08:17 |
| scorp007 | umm? Two separate ray tracing projects? | 08:17 |
| Anteru | With two people, it could work, for one, the 12 weeks aren't enough probably ... | 08:17 |
| scorp007 | oh, I see now | 08:17 |
| scorp007 | will they work together on the same project/ | 08:17 |
| scorp007 | ? | 08:17 |
| pgregory | Anteru: they can't work together on the project, they have to work separately | 08:17 |
| Anteru | Oh noes :/ | 08:17 |
| scorp007 | then are they both somewhat unrelated raytracing projects? | 08:18 |
| scorp007 | I hope they won't end up re-doing each other's work | 08:18 |
| Anteru | Somehow ... if both get accepted ... | 08:18 |
| pgregory | nope, they are both the same, just applications by two different students. | 08:18 |
| scorp007 | oh | 08:18 |
| scorp007 | What happens if both get accepted? | 08:18 |
| pgregory | they both do raytracing | 08:19 |
| scorp007 | but will their work conflict? | 08:19 |
| pgregory | I wouldn't accept both results into the project codebase | 08:19 |
| Anteru | You can pick the better one ... | 08:19 |
| scorp007 | then it would kind of be pointless for them both to work on it, only to throw it away. | 08:20 |
| pgregory | yep, but there's nothing I can do about it | 08:20 |
| pgregory | also, I believe Google encourages such competition. | 08:20 |
| scorp007 | oh? Interesting | 08:20 |
| Anteru | And competition doesn't hurt the code quality ^ | 08:20 |
| scorp007 | perhaps the students could each work on a particular subsystem of raytracing, so their work complements each other. | 08:21 |
| pgregory | http://code.google.com/support/bin/answer.py?answer=60314&topic=10727 | 08:21 |
| Anteru | I'd say we wait until we know who has been accepted :) | 08:21 |
| scorp007 | oh ok | 08:22 |
| scorp007 | I would much rather the students work on two separate things, for the better of Aqsis. | 08:22 |
| pgregory | so would I, but if they both want to do RT, what can we do? | 08:23 |
| scorp007 | not much. | 08:23 |
| *** cgTobi has joined #Aqsis | 08:31 |
| *** ChanServ sets mode: +o cgTobi | 08:31 |
| pgregory | hi Tobi | 08:37 |
| *** render has joined #aqsis | 08:37 |
| Anteru | Gooood mooorning tobi, render | 08:37 |
| cgTobi | hi all | 08:37 |
| *** cgTobi sets mode: +vv pgregory_ render | 08:37 |
| cgTobi | It's the final day for SoC submission, right? | 09:19 |
| scorp007 | guess so | 09:19 |
| *** kaz has joined #aqsis | 09:19 |
| kaz | hiya | 09:19 |
| scorp007 | hi kaz | 09:20 |
| pgregory | hi kaz | 09:20 |
| kaz | pgregory: i'm one of the guys that submitted a rt proposal, and since apparently students are allowed to update their proposal only once, i replied to your comment with a comment also. just wanted to make sure you had the chance to look at it (i don't know how this stuff works on the mentor side - whether you get notified after your comment has been answered with an update and don't get notified about comments to comments or... well, just wanted to | 09:20 |
| kaz | make sure ;) ) | 09:20 |
| pgregory | kaz: I don't get notified, but I'm monitoring it closely. | 09:20 |
| pgregory | i saw your comment, and that clarifies things quite a bit. | 09:20 |
| kaz | oh, ok | 09:20 |
| *** cgTobi sets mode: +v kaz | 09:20 |
| kaz | sorry to bother you about it then | 09:21 |
| pgregory | kaz: I'm quite happy with your proposal as it stands now | 09:21 |
| pgregory | no bother at all | 09:21 |
| kaz | i was just wondering - do you guys know how many spots you get? | 09:21 |
| kaz | or does google decide on that later? | 09:22 |
| Anteru | Hi kaz | 09:23 |
| kaz | hey Anteru | 09:23 |
| pgregory | I set a 'preferred' number, but as I understand that, it's really a max, and it's up to Google how many applications get accepted. | 09:23 |
| scorp007 | I'd set it as high as allowed :) | 09:24 |
| kaz | difintely :D | 09:24 |
| kaz | eh... definitely | 09:24 |
| pgregory | scorp007: not really, as there are only 4 mentors, and we're all quite busy. | 09:24 |
| scorp007 | well, depends on how much mentoring is required. I wouldn't know | 09:25 |
| pgregory | for the sort of tasks that are being proposed, I'd suspect quite a lot | 09:25 |
| scorp007 | but I guess students will have a lot of questions | 09:25 |
| kaz | i'm quite surprised you got so little applications - i think i remember reading some organizations got over a hundred last year | 09:27 |
| kaz | but i than again - your projects probably require a bit more work than a site revamp or a new widget ;) | 09:28 |
| scorp007 | well, it is our first time in SoC | 09:28 |
| Anteru | Aqsis is not as well known as say Apache | 09:28 |
| scorp007 | and the use of Renderman is not as widespread as a webserver, for instance. | 09:29 |
| kaz | it's definitely not something you learn at school... | 09:29 |
| kaz | anyways, off to do some work. and maybe grab a bite to eat first... | 09:30 |
| kaz | bye | 09:30 |
| scorp007 | cya | 09:30 |
| scorp007 | render == renderguy? | 09:31 |
| kaz | thanks for all the info :) | 09:31 |
| *** kaz has quit IRC | 09:31 |
| pgregory | scorp007: no, render != renderguy | 09:31 |
| scorp007 | ok | 09:31 |
| scorp007 | has renderguy (I forget his name), had a chance to troubleshoot the wiki? | 09:32 |
| pgregory | don't know yet, Leon is away for a couple of days. | 09:33 |
| scorp007 | oh yeah, Leon's the name. | 09:33 |
| scorp007 | ok, no problem | 09:33 |
| pgregory | he did say he was going to take a look at the weekend, so it might be worth trying. | 09:33 |
| scorp007 | does this mean that every time we update the wiki, it duplicates the whole page as a revision, or that it simply does not store history/ | 09:34 |
| scorp007 | ? | 09:34 |
| pgregory | I think at the moment, it's not storing history. | 09:35 |
| scorp007 | ok | 09:35 |
| pgregory | which is a bit of a problem. | 09:35 |
| scorp007 | very much so | 09:35 |
| * Anteru just imagines someones wants to damage the wiki by editing to spam, then we have a hard time to get back ... | 09:42 |
| pgregory | I'll take a look, but I can't promise anything... | 09:42 |
| pgregory | fixed | 09:58 |
| cgTobi | cool, cheers Paul | 10:02 |
| Anteru | well done | 10:02 |
| tcolgate | mornin' | 10:26 |
| Anteru | Morning minty | 10:26 |
| cgTobi | morning Minty | 10:26 |
| pgregory | morning | 10:26 |
| tcolgate | Check disk space and permissions on the directories it writes to. | 10:27 |
| pgregory | tcolgate: yep, fixed | 10:27 |
| pgregory | it was permissions, Leon likes to lock things down, sometimes a little to vigorously. | 10:28 |
| tcolgate | ah yes, missed that :) | 10:28 |
| scorp007 | ah, cool, the wiki's already fixed? | 10:33 |
| pgregory | should be, only briefly tested, all previous changes are lost, but should work from here on in, unless someone changes the permissions again. | 10:34 |
| scorp007 | looks like it's working well, I'm testing on the Playground | 10:34 |
| scorp007 | make sure you let Leon know not to undo your fixes ;) | 10:35 |
| Anteru | bbl | 10:41 |
| scorp007 | Paul, do you think that perhaps the new advanced framebuffer, and the flipbook should be the same project? | 10:41 |
| pgregory | scorp007: they could share some functionality, yes | 10:42 |
| pgregory | I have mentioned that possibility to the student who made the application. | 10:42 |
| scorp007 | but shouldn't they essentially be the same application? Kind of like Houdini's MPlay? | 10:42 |
| pgregory | that's one possibility. | 10:42 |
| scorp007 | Houdini renders to Mplay, and the user plays back his sequences in it | 10:42 |
| scorp007 | I think i-display is aiming at the same thing | 10:43 |
| scorp007 | But then again, other apps do it with two separate applications, such as Maya/fcheck, 3dsmax/RAM player | 10:48 |
| scorp007 | So I don't mind either, as long as its fast. | 10:48 |
| Anteru | Well, it should be no problem if there is some overlap between two projects ... | 10:48 |
| scorp007 | well, hopefully they will use a common shared library | 10:48 |
| scorp007 | I'm very much liking fltk as a GUI toolkit from my limited exposure to it, over other toolkits | 10:50 |
| scorp007 | I just hope they're version 2 becomes stable in the near future | 10:50 |
| tcolgate | Flipbook functionality is one of the things I considered for my intial idea for the DB project. | 10:50 |
| scorp007 | DB? | 10:50 |
| tcolgate | egads, two applicants for doing RT!!! | 10:51 |
| scorp007 | hehe, just found out? | 10:51 |
| cgTobi | I guess DB == FB !? | 10:51 |
| scorp007 | tcolgate, are you happy, or annoyed? | 10:52 |
| * tcolgate really wishes he'd just got on and done it "his way" now. | 10:55 |
| tcolgate | scorp007: nervous. | 10:55 |
| scorp007 | you don't like their proposals for it? | 10:55 |
| scorp007 | well, you are a mentor, you have input to persuade them. | 10:56 |
| * scorp007 hasn't read the proposals, so doesn't know | 10:56 |
| scorp007 | but these things should be publically discussed anyway, so the whole community can see what's going on. | 10:57 |
| Anteru | Minty, the C-way, eh? ;) | 10:57 |
| scorp007 | I thought Aqsis is written in C++? | 10:57 |
| Anteru | it's an insider joke :) | 10:58 |
| scorp007 | I guessed so. | 10:58 |
| Anteru | Certain developers have different preferences, you know :P | 10:58 |
| tcolgate | The second one looks a little week, I suspect he's just read my notes and doesn't really realise what a mess he is about to get into, it could bea language problem I suppose. | 10:58 |
| Anteru | tcolgate : Is the second one riseven? | 10:59 |
| pgregory | tcolgate: Jose has just added a comment that gives a little more detail. | 10:59 |
| scorp007 | by language, do you mean natural, or pragmatic? | 10:59 |
| Anteru | He's Spanish, he said his English is not that great ^ | 10:59 |
| scorp007 | oh ok | 10:59 |
| tcolgate | pgregory: yes, though the update doesn't fill me with confidence. | 11:03 |
| tcolgate | The first of the two RT proposals looks a bit more promising, though I think we'd have to talk him out of the SSE stuff first. | 11:03 |
| pgregory | not interested in SSE at all, that really doesn't matter | 11:03 |
| tcolgate | indeed | 11:04 |
| pgregory | I seriously doubt either of the students really have a good handle on how much work is involved. | 11:04 |
| pgregory | I think perhaps scorp007's suggestion of splitting the project into two parts if they both get accepted would be good. | 11:04 |
| tcolgate | agreed, the first chap seems to have done a bit more research though. | 11:04 |
| Anteru | Hm | 11:05 |
| tcolgate | possibly, certainly a geometry cache has other useses (for re-rendering for isntance), perhaps we could convince them to work just on that. | 11:06 |
| Anteru | Yeah. | 11:06 |
| Anteru | Moreover, he only gets the money if he finishes. | 11:06 |
| Anteru | So it's better to set smaller goals that will be reached instead of too big ones ... | 11:06 |
| pgregory | tcolgate: but a geometry cache isn't related to RT per se. | 11:06 |
| tcolgate | money? | 11:06 |
| Anteru | Yeah, they get 4500$ for their work? | 11:07 |
| Anteru | If they finish it in time ... | 11:07 |
| scorp007 | We must explain that we prefer quality over quantity. I would rather see a smaller project done well, than a half-baked attempt at a larger one. | 11:07 |
| tcolgate | No, it doesn't sound as sexy, but the data strcutres would be sueful in the grid cache for RT anyway. | 11:07 |
| Anteru | plus 500$ for Aqsis per student. | 11:07 |
| Anteru | Which means best case 2500$ for Aqsis :) and 22500$ for the students | 11:07 |
| tcolgate | Any RT system for a REYEs system that doesn't employ some kind of grid cache is either wrong, or alot cleverer than I can possily imagine. | 11:08 |
| pgregory | tcolgate: I was thinking the split would be more like, 1 person does geometry caching, and the other does the ray traversal, along with the issues related to shading. | 11:08 |
| tcolgate | hmm, could they work on one of them without the other in place? | 11:08 |
| pgregory | tcolgate: true, probably not | 11:08 |
| pgregory | it's difficult, as RT is a really big one, and the time is limited. | 11:09 |
| scorp007 | perhaps if you provide them with a well-defined interface to implement? Or is designing that part of their job/ | 11:09 |
| scorp007 | ? | 11:09 |
| tcolgate | yeah, and, as you know, it's something I'm apssoinate about getting right. | 11:09 |
| tcolgate | I imagine the problem there is that they are going to want to work on something "sexy" | 11:09 |
| scorp007 | tcolgate, that's why you're a mentor for them. To guide them to do it right. | 11:10 |
| Anteru | Yeah ^ You have to show them that a grid cache can be sexy, too :) | 11:10 |
| pgregory | I think there will be a 'lot' of mentoring on the RT one(s). | 11:10 |
| Anteru | :) | 11:10 |
| scorp007 | likely | 11:10 |
| tcolgate | yes, infact, more than likely I think we'd all have to dig in and help them write the bloodey thing aswell. | 11:11 |
| pgregory | we'd have to be very very careful about that, remember Google are paying these people. | 11:12 |
| tcolgate | yes, true enough. | 11:12 |
| * tcolgate thinks money makes things so damned complicated. | 11:12 |
| * pgregory thinks he'd very much like his life to be a little more 'complicated' then ;-) | 11:13 |
| tcolgate | :) | 11:13 |
| * tcolgate finds the complication to be all too shortly lived. | 11:13 |
| Anteru | Hmm ... | 11:14 |
| scorp007 | Essentially, in the first week or so, make sure they discuss how exactly they are going approach whatever they're doing, so it sits right with you guys, and you have an agreement, before they run off and start coding their own fantasy. | 11:14 |
| Anteru | hrhr | 11:15 |
| scorp007 | so you don't end up getting something useless at the end of the 12 weeks... | 11:15 |
| pgregory | there is a period before the 'project' proper begins, during which we will be doing just that. | 11:16 |
| tcolgate | For the simple multi thread support I think it's not too bad, the code is simple and it's really about testing and implementing all the wierd fiddly bits we haven't thought of yet. | 11:16 |
| scorp007 | Paul, ah, ok, I figured you had it all planned out ;) | 11:17 |
| pgregory | scorp007: April 11: List of accepted student applications published. | 11:17 |
| tcolgate | If the chap wants to go for the secy approach thenwe've got alot more work, but even then, it should be doable. if he comes up with his own crazy plan then we will need a week staring at white boards to figure out if what he wants to do is even valid. I'm rather scared of the latter option. | 11:18 |
| pgregory | scorp007: May 28: Students begin coding. | 11:18 |
| scorp007 | pgregory, wow, thats a lot later than I thought | 11:18 |
| tcolgate | I take it there is some kind of sign off process, if one of these RT guys should go running off and writing an utterly useless RT hider that is no god to us, does he still get paid? | 11:19 |
| pgregory | http://code.google.com/support/bin/answer.py?answer=60325&topic=10729 | 11:19 |
| Anteru | ^ No | 11:19 |
| pgregory | tcolgate: we do midterm evaluations, and final evaluations, the decision to pay is based on those evaluations. | 11:19 |
| pgregory | at least partially | 11:20 |
| scorp007 | I guess the interim period before the coding starts seems reasonable. Should give you guys enough time for the design phase. | 11:21 |
| tcolgate | Cal me cynical (unsympathetic, 9 down), but there is no way in hell someone is coming into this project fresh and writing us an RT system in 4 months. | 11:22 |
| tcolgate | mentor or no mentor. | 11:22 |
| scorp007 | unless he has extensive history in raytracing... | 11:22 |
| pgregory | tcolgate: then we're in trouble | 11:22 |
| Anteru | With the proper mentor ... :) | 11:23 |
| scorp007 | Hopefully the application for this project will be well versed in what he is applying for. Not intending to learn in on the fly as he is coding, from his mentors. | 11:23 |
| tcolgate | paul: we've often quoted atleast 6 moths for the job, I'd say it'd take be atleast that, and that'd be relatively full time. | 11:23 |
| scorp007 | s/application/applicant/g | 11:23 |
| pgregory | tcolgate: when I quoted 6 months, I wasn't planning on quitting my day job to do it. | 11:24 |
| tcolgate | quite, my point being that it'd take me that i I were doing it full, and a shit load longer if I were doing it part time. | 11:25 |
| pgregory | hmm, I'd considered 6 months part time, to get the basics working, nothing too clever to begin with. | 11:26 |
| tcolgate | paul: do you reckon you could do it in 3/4 months if you were doing it full time? | 11:26 |
| scorp007 | And a shitload longer than that if the implementor didn't know what he was doing. | 11:26 |
| scorp007 | tcolgate, has it already been designed sufficiently for someone to start the implementation? | 11:27 |
| pgregory | yeah, basics | 11:27 |
| tcolgate | Well, thye have to know what they are doing, and they have to know C++, you are talking a good months to familiarise yourself with all the relevant bits of aqsis (assuming you can mostly ignore a few larger chunks, like the RIB parser and so on). | 11:27 |
| pgregory | tcolgate: they have 6 weeks to familiarise | 11:28 |
| Anteru | One has written a ray-tracer already, so he should know a bit what he does (not sure how complex that ray-tracer was though). | 11:28 |
| tcolgate | scorp007: nope, I have a plan, but that is more of an academic description of the technique I like rather than anything specific. I've not even considered the grid cacheing yet. | 11:29 |
| tcolgate | Anteru: I've writen a ray tracer, I could probably do you a ball and a grid floor in the next few hours, that's a million miles away from wahat is needed here. | 11:29 |
| Anteru | Yeah, I know. I just hope he has worked on a PBRT-style one :) | 11:30 |
| scorp007 | tcolgate, where in your opinion does most of the challenge lie? | 11:30 |
| Anteru | I.e. not /that/ kind of ray-tracer ... | 11:31 |
| Anteru | I suppose everyone here could write the one you mentioned in a few hours ^ | 11:31 |
| tcolgate | Right, the key prpoblem is that implements a truly combind REYEs and rendering architecture is not really lie writing a GI renderer with all the nice integals and energy stuff. | 11:36 |
| tcolgate | It's pragmatic, you have a defined pipeline to work in, for good reasons, it's memory efficient and designed to render really truly massive detailed scenes (GI renderers aren't good at that). | 11:37 |
| tcolgate | The challenges in the approach I have outlined are pretty much inthe grid cacheing. | 11:38 |
| *** riseven has joined #aqsis | 11:38 |
| riseven | hi all | 11:38 |
| scorp007 | ok | 11:38 |
| scorp007 | hi riseven | 11:38 |
| riseven | i've just submitted my rt proposal | 11:39 |
| riseven | there is no single link, because i don't know the exact deadline hour | 11:40 |
| tcolgate | Hi | 11:40 |
| riseven | but i can provide link to almost everything i tell on it :) | 11:40 |
| tcolgate | beyond the basic stuff, the really sexy stuff is the potential for ray scheduling and implementing a nice serialisation interface for the shadervm. | 11:41 |
| riseven | i have some preliminar ideas about ray scheduling | 11:42 |
| pgregory | riseven: just read | 11:42 |
| pgregory | you'll need to give more information about the geometry caching. | 11:42 |
| pgregory | you mention that Reyes cannot discard primitives, but that is exactly the way Reyes works, it has to. The RT subsystem will need to work in separation. | 11:43 |
| *** cgTobi sets mode: +v riseven | 11:43 |
| pgregory | I'll add these comments to the proposal thread for reference. | 11:44 |
| riseven | i know reyes discards primitives | 11:45 |
| riseven | what i mean is that a rt can't do that | 11:45 |
| Anteru | hm? | 11:45 |
| Anteru | it can discard geometry, it just has to re-tesselate/shade it as soon as it is needed again ... | 11:48 |
| *** cgTobi has quit IRC | 11:51 |
| *** |rt| has quit IRC | 11:51 |
| *** render has quit IRC | 11:51 |
| *** scorp007 has quit IRC | 11:51 |
| *** AlexK has quit IRC | 11:51 |
| *** pgregory_ has quit IRC | 11:51 |
| *** pgregory has quit IRC | 11:51 |
| *** Anteru has quit IRC | 11:51 |
| *** ShortWave has quit IRC | 11:51 |
| *** Auralis has quit IRC | 11:51 |
| *** tcolgate has quit IRC | 12:08 |
| *** riseven has quit IRC | 12:09 |
| *** pgregory has joined #aqsis | 12:13 |
| *** tcolgate has joined #aqsis | 12:13 |
| *** Auralis has joined #aqsis | 12:13 |
| *** ShortWave has joined #aqsis | 12:13 |
| *** pgregory_ has joined #aqsis | 12:13 |
| *** irc.freenode.net sets mode: +ovvv pgregory Auralis ShortWave pgregory_ | 12:13 |
| *** AlexK has joined #aqsis | 12:13 |
| *** |rt| has joined #aqsis | 12:13 |
| *** cgTobi has joined #aqsis | 12:13 |
| *** render has joined #aqsis | 12:13 |
| *** irc.freenode.net sets mode: +vvv AlexK |rt| render | 12:13 |
| *** ChanServ sets mode: -o pgregory | 12:14 |
| *** ChanServ sets mode: +o cgTobi | 12:14 |
| *** cgTobi sets mode: +vv pgregory tcolgate | 12:14 |
| *** cgTobi sets mode: +o pgregory | 12:15 |
| *** riseven has joined #aqsis | 12:17 |
| riseven | hi | 12:17 |
| riseven | have been a server crash, or it was only me who can't connect? | 12:18 |
| pgregory | riseven: no, freenode is going through a bit of a problem patch at the moment. | 12:18 |
| riseven | ah | 12:18 |
| riseven | i have updated the proposal | 12:18 |
| pgregory | riseven: just reading. | 12:19 |
| riseven | :D | 12:19 |
| *** tcolgate has left #aqsis | 12:20 |
| *** tcolgate has joined #aqsis | 12:25 |
| tcolgate | oh dear, it's all over the palce. | 12:25 |
| pgregory | it'll settle | 12:25 |
| *** cgTobi sets mode: +vv riseven tcolgate | 12:28 |
| *** Aren has joined #aqsis | 12:29 |
| tcolgate | riseven: still here? | 12:30 |
| riseven | yes | 12:33 |
| tcolgate | aha | 12:33 |
| tcolgate | Could you elaborate a little on your C++ experience, aqsis is not a small project and the time frame on the RT job is going to be very tight as it is. | 12:34 |
| riseven | i can't modify the detailed | 12:35 |
| riseven | it's ok if i write it as a comment? | 12:35 |
| tcolgate | In here, or in a comment on the application will be fine. | 12:35 |
| riseven | ok | 12:35 |
| pgregory | riseven: here is ok, everyone relevant is here, or reads the logs. | 12:35 |
| riseven | i have been working c++ since i was 15 | 12:35 |
| riseven | working in complex things suchs as compilers | 12:35 |
| tcolgate | Are there any large open source C++ projects you've worked on? | 12:36 |
| riseven | not so large | 12:36 |
| tcolgate | Have you taken a look at the code yet? | 12:37 |
| riseven | yes i have | 12:37 |
| *** cgTobi sets mode: +v Aren | 12:37 |
| riseven | well, the 3d strategy game we did two years ago was | 12:37 |
| riseven | mm | 12:37 |
| riseven | about 110 classes | 12:37 |
| tcolgate | Your proposal is very much in line with my own ideas on the RT sub-system, which is a good thing, I just want to make sure you understand just hw big the task is. | 12:37 |
| riseven | :D | 12:37 |
| riseven | yes i know how big is | 12:38 |
| riseven | i now know | 12:38 |
| riseven | that is much more that i have guessed when i readed "ray tracer" | 12:38 |
| tcolgate | aqsis is very heavily template (and STL) driven, so if you are going to "hit the ground running", knowledge of the language is an important thing. | 12:38 |
| riseven | last year | 12:38 |
| pgregory | just as side question, would you be prepared to cut back on the project? | 12:39 |
| riseven | we do a AI lib | 12:39 |
| riseven | that used templates | 12:39 |
| riseven | i designed a reference-like pointer system | 12:39 |
| riseven | using templates | 12:39 |
| riseven | mmm, i dind't understand "cut back on the project" | 12:40 |
| riseven | my english.... | 12:40 |
| pgregory | sorry | 12:40 |
| tcolgate | riseven: We are starting to think that the RT project might be better split into smaller parts with several candidates, if it can be done. | 12:41 |
| pgregory | I mean, if I were to suggest that it is more achievable to for example, just do the geometry caching part of raytracing, would you be willing to undertake that as a project, or are you keen to specifically do raytracing. | 12:41 |
| riseven | i don't have such a problem | 12:41 |
| tcolgate | For isntance, serializability and scheduling for the shader vm interface could be implemented serperately from the grid/geometry cache. | 12:41 |
| riseven | the parts i like more are the world representation / scheduling | 12:42 |
| riseven | so whichever part i have to do | 12:42 |
| riseven | it will like me | 12:42 |
| riseven | and i have previous experience with RT, BSPs (see my paper :) ) and interpreters | 12:44 |
| riseven | so i feel... | 12:44 |
| riseven | prepared? | 12:44 |
| riseven | so i think im capable | 12:45 |
| riseven | :) | 12:46 |
| * tcolgate really needs to get on wth some proper work. | 12:47 |
| tcolgate | riseven: We will need to talk to the other potential RT candidate and see if he is happy to split the work. | 12:49 |
| riseven | ok | 12:50 |
| riseven | there are too much people intereseted in RT? | 12:50 |
| tcolgate | In al ikelyhood, neither of you would be working on "Ray Tracing", for SoC, but on two components that would then form the major part of the ray tracing system. You could then stick around after to implement the actual RT side of things with others, but that would not be part of SoC. | 12:51 |
| tcolgate | That would be better for you in many ways as it makes your SoC goals more achievable. | 12:51 |
| riseven | that's great | 12:51 |
| tcolgate | riseven: No, not too many, we have two candidates (including you), that we like, but it really i a very very big job. | 12:51 |
| riseven | i mean to continue working on aqsis after soc | 12:52 |
| riseven | but i think that people that chooses projects like this, is because they really like it | 12:52 |
| tcolgate | I would advise starting to look into the code ASAP. | 12:52 |
| riseven | im doing that right now | 12:52 |
| riseven | i started trying to solve bugs | 12:53 |
| tcolgate | Also, I have a page on the Wiki relating to my RT ideas (very much in line with yours), but it is a long way from containing enough detail to be very useful, it is more a justification for why I want things done that way. | 12:53 |
| tcolgate | excellent. | 12:53 |
| riseven | because is a less boring way to learn the code | 12:53 |
| riseven | :) | 12:53 |
| tcolgate | indeed. | 12:53 |
| riseven | ah, i have seen that you have just released 1.2 | 12:54 |
| riseven | can i ask what major features are planned for next release? | 12:54 |
| pgregory | raytracing :-) | 12:57 |
| pgregory | seriously, speed is our main concern at the moment. | 12:57 |
| *** Anteru has joined #aqsis | 12:58 |
| riseven | hi anteru | 12:58 |
| Anteru | hi riseven | 12:58 |
| Anteru | re | 12:58 |
| *** cgTobi sets mode: +v Anteru | 12:59 |
| Anteru | thnx tobi | 12:59 |
| cgTobi | hi Anteru | 12:59 |
| *** Aren has quit IRC | 13:11 |
| tcolgate | pgregory: and RiResource support for MtoR ;) | 13:12 |
| *** mafm has joined #aqsis | 13:12 |
| Anteru | hi mafm | 13:13 |
| mafm | hi | 13:13 |
| *** cgTobi sets mode: +v mafm | 13:13 |
| mafm | thanks :) | 13:14 |
| tcolgate | Let me guess, you've just submitte your proposal for RT support in aqsis? | 13:14 |
| *** pgregory has quit IRC | 13:15 |
| *** pgregory has joined #aqsis | 13:15 |
| mafm | nope, I submitted the one about threads a few days ago | 13:15 |
| *** ChanServ sets mode: +o pgregory | 13:15 |
| pgregory | oops | 13:16 |
| pgregory | what did I miss? | 13:16 |
| mafm | 19 seconds of silence | 13:16 |
| Anteru | actually, mafm pasted a link to his RT implementation and it seems to work fine ... | 13:17 |
| mafm | RT == raytracing? | 13:17 |
| Anteru | yeah, hey, you spoil my joke :P | 13:17 |
| riseven | hi mafm | 13:18 |
| Anteru | you should have said something like: "A bit left to optimize but pretty happy as it stands" or something like that :P | 13:18 |
| tcolgate | mafm: Hi, sorry, me being sarcastic again. | 13:19 |
| tcolgate | mafm: I am your potential Mentor for the multi-threading work, I am also the chap that should have done the work in the first place, so I am probably the person to throw question at. | 13:20 |
| mafm | well, I really intend to implement a micro-kernel tu run aqsis directly over it and so on, so we get the better performance | 13:20 |
| mafm | but it was supposed to be a secret :S | 13:20 |
| Anteru | Good idea, it could run on my new RISC-CPU I'm just about to invent :P | 13:21 |
| tcolgate | sounds like a plan, I think paul Anteru can mentor you on that one, | 13:21 |
| * tcolgate runs. | 13:21 |
| mafm | it'll integrate nicely =) | 13:21 |
| * Anteru runs after Minty | 13:21 |
| tcolgate | mafm: On a more serious note, have you had a look at the codebase yet? | 13:22 |
| mafm | not much, just tried to compile aqsis (successfully) a while ago at home | 13:22 |
| tcolgate | Ok, that is a start. | 13:23 |
| tcolgate | What is your main developement platform? | 13:23 |
| mafm | I have to do a lot of work this semester in order to have free time at summer :D | 13:23 |
| mafm | linux, Debian | 13:23 |
| tcolgate | ok | 13:23 |
| tcolgate | Did you see my reply ont he forum about the two possible approaches? | 13:23 |
| Anteru | tcolgate: About Boost.Threads | 13:24 |
| mafm | I was about to read it now :D | 13:24 |
| tcolgate | Well it was mostly about the two possible method of implementation. | 13:24 |
| Anteru | They leak memory on windows and are being rewritten ... not sure how good they are on linux though. | 13:25 |
| tcolgate | They leak about 128 bytes on windows from what I've read, and that was a very veyr long itme ago. | 13:25 |
| Anteru | Yeah, anyway ... | 13:26 |
| tcolgate | That 128 bytes wasn't even per thread, it seemed to be a flat rate loss of a few bytes when the library was used due to issues with the ddl init and shutdown stuff. | 13:26 |
| Anteru | Yup. Anyway, they want to rewrite it. | 13:26 |
| Anteru | They are rewriting it. | 13:26 |
| tcolgate | As it standsa the API looks good, and clean, and we already use bits of boost, so, to my mind, we either use boost, or we write our own abstraction. | 13:27 |
| Anteru | It's nothing serious if we don't want other dependecies we can stick with Boost.Threads ... just something to be aware of. | 13:27 |
| mafm | I saw something about being replaced by Boost.Future IIRC (kind of weird name) | 13:28 |
| Anteru | Yeah, that's something from "Concur" | 13:28 |
| tcolgate | In the long term boost::threads, in whatever form it takes, will be the thing to use (it'll practically be part of the standard), so rather than rewrite for random libsomethreadlib we might aswell stick with boost at migrate if they change thier api. | 13:28 |
| mafm | if they maintain the semantics between the implementations, and probably they'll be similar in any library, changing it won't be very hard | 13:29 |
| Anteru | Sounds like a plan | 13:29 |
| tcolgate | mafm: We basicaly have two approaches we have already considered for threading. They both have a bit of an agenda behind them. | 13:30 |
| tcolgate | You may wel be able to come up with something better yourself. | 13:31 |
| tcolgate | Basically, we already havesome ideas, but we are open to new ones, I'm not looking to force anyone to write anything that I was too lazy to do myself. But, to so that you know, we have had quite a bit of debate about threding before and there are a couple of plans out there. | 13:32 |
| mafm | the boost and hand-made implementation? | 13:35 |
| tcolgate | nope, sorry, I'm rambling a bit. | 13:35 |
| tcolgate | We have two proposals for what we want to multi-thread and why. | 13:35 |
| mafm | ah ok :D | 13:36 |
| tcolgate | The first relates to Ray Tracing. Basically, the process we have devised for ray tracing relies on shading that can be suspended), one implication of this is that we havea thread sage, reentrant, shaer vm. | 13:36 |
| pgregory | not really multi-threading per se, more thread safety though. | 13:37 |
| tcolgate | Now, that doesn't actually imply that shading *has* to be multi threaded, just that it has to be thread safe. So my plan was, make the shading multi threaded, then we know it is thread safe :) | 13:37 |
| tcolgate | pgregory: eaxctly. | 13:38 |
| mafm | (one note about threading libs... I have close to zero idea about windows, so I prefer to use a standard 3rd party lib too, as I wrote in the proposal) | 13:40 |
| tcolgate | Now, that is vision one, it isn't really about performance, it's about making RT a little easier, and doing it right. It also has some potential performance advantages, but we have other perforance issues, so threading hte shadervm isn't going to bea huge performance win at this time. | 13:41 |
| tcolgate | mafm: yes, again, boost looks lik a good choice for platform independence. | 13:41 |
| tcolgate | mafm: ...with me so far? | 13:41 |
| * pgregory concurs | 13:41 |
| mafm | sorry I'm multitasking a bit, I'm currently reading this log :D | 13:42 |
| tcolgate | no probs, I have a habit of typing alot, and ranting a bit. | 13:42 |
| mafm | OK, read until now | 13:43 |
| tcolgate | mafm: with me? I can move on to vision 2 | 13:47 |
| mafm | yep | 13:47 |
| tcolgate | right... | 13:50 |
| tcolgate | The second approach is really geared toward distributed rendering | 13:50 |
| mafm | several machines, or only one? | 13:51 |
| pgregory | initially only one | 13:52 |
| pgregory | although the proposed approach could be adapted to work across a network. | 13:52 |
| tcolgate | The idea is to imeplement it with full distribution in mind, but initially just to deal with multiple threads. | 13:52 |
| mafm | by the way, does it really need to be with threads or could it be done with multiple processes? | 13:54 |
| tcolgate | So you can ignore all the tricky network protcol gubbins, serialisatoin ad all that, but the designa nd terminology around it should try and keep the bigger picture in mind. | 13:55 |
| pgregory | it'll work with either, but the implementation will probably be easier for threads initially. | 13:55 |
| tcolgate | mafm: My proposal really needs to be thread based. | 13:55 |
| tcolgate | t is important to state that we are not simply talking about dicing up the image inot little bits and rednering each in a seperate process/thread. | 13:56 |
| mafm | I see | 13:56 |
| tcolgate | You could do that now with cropping and a render farm shell script to manage the work. | 13:58 |
| mafm | so my proposal is more like to this second approach, right? | 13:58 |
| tcolgate | You could do either, it depends what you want to do. | 13:59 |
| tcolgate | As I said in the forum post, in all likelyhood we will end up with both thigs actually happening. | 14:00 |
| tcolgate | The second proposal results in far more of the REYEs pipline being handed out to threads, so would, in theory, have bigger speed gains, but again, it's not really about speed at this stage, it's about distribution (think of NUMA style systems). | 14:02 |
| *** ShortWave has quit IRC | 14:02 |
| *** ShortWave has joined #Aqsis | 14:02 |
| *** [1]ShortWave has joined #aqsis | 14:03 |
| tcolgate | The being said, proposal 2 is harder :) | 14:03 |
| tcolgate | I can well imagine us ending up with both anyway, architecturally it makes sense. | 14:04 |
| mafm | one thing that I'm worried about is how to know the number of "cores" or CPUs available | 14:04 |
| tcolgate | mafm: I wouldn't worry about that. | 14:04 |
| pgregory | mafm: you don't, you leave that decision up to the user. | 14:04 |
|