http://pasteall.org/4795
* kaito has changed the topic to: Meeting time!
<DingTo> Current projects, 2.5, 2.49 status, GSOC ?
<kaito> yeah seems like it!
<kaito> maybe we should appoint DingTo to make meeting minutes!
<DingTo> nah
<theeth> yes
<theeth> majority wins!
<elubie> brecht: would you have a few minutes after the meeting - I have some issues with current MS
VC compile for 2.5 since this merge: http://lists.blender.org/pipermail/bf-blender-cvs/2009-March/01
8511.html
<kaito> ok; i'll do :)
<brecht> elubie, ok
<elubie> brecht: (weird crash in ghost during debug)
<kaito> dingto can throw rotten fruit at people who talk off topic
<elubie> brecht: cool
Current projects
* kaito has changed the topic to: Meeting time! 1) current projects
<shul> elubie: do u use ffmpeg ?
* shul ducks as a rotten banana flies above him
<elubie> shul: yes, had some library mixup too but that didn't solve it. Let's continue after meetin
g
<shul> elubie: try compiling without and see
* zolar_czakl (n=zolar@host54-134-dynamic.4-87-r.retail.telecomitalia.it) has joined #blendercoders
<Moguri> Wow, I think I need to restart, things are getting goofy :s
* Moguri has quit ("brb")
<theeth> no current projects talk?
<DingTo> ben2610: GE updates?
<ben2610> API cleanup in progress
<ben2610> We're boosting to finish for 2.49
<kaito> nice
<ben2610> On my side, I'm implementing Bullet dbvt broadphase to view frustrum culling and occlusion
culling in the BGE
<theeth> ben2610: are you going to review dfelinto's dome code for 2.49?
<ben2610> theeth: normally yes
<ben2610> when is 2.49 btw?
* Moguri (n=Moguri@c-67-185-125-15.hsd1.wa.comcast.net) has joined #blendercoders
<theeth> nothing planned yet, IIRC
<theeth> when you guys are done, I guess
<ben2610> ok :-) in a few weeks then
* schlaile (n=chatzill@p5DC0A987.dip.t-dialin.net) has joined #blendercoders
* schlaile (n=chatzill@p5DC0A987.dip.t-dialin.net) has left #blendercoders
<kaito> ehh
* schlaile (n=chatzill@p5DC0A987.dip.t-dialin.net) has joined #blendercoders
* blenderme has quit (Read error: 110 (Connection timed out))
<kaito> schlaile: any ffmpg note for meeting?
<schlaile> kaito: works for me?
<schlaile> :)
<Moguri> :)
<Moguri> I can compile :D
<andrecastelo> I can't
<Tr3B> where can i make a request for the Python API?
* Moguri pokes ideasman42__
<kaito> Tr3B: do that at end of meeting
<Tr3B> i need something to be disabled in editbones_to_armature
<Tr3B> ok
<Tr3B> when is the end of the meeting?
<DingTo> you'll see at the topic
<Moguri> Tr3B: Whenever it ends :P
<kaito> 90 mins?
<Tr3B> ok
<DingTo> any other current projects?
<ideasman42__> Tr3B, ask in PM
<ideasman42__> migius's matrix re-gigging?
<Moguri> I've been to one that lasted like, 3~4 hours because we were talking about some python topi
c the whole time XD
* Rapp (n=schmitz@3-083.vpn.RWTH-Aachen.DE) has joined #blendercoders
<DingTo> i suggest to go on then?
<kaito> nice i like short meetings :)
Blender 2.5 progress
* kaito has changed the topic to: Meeting time! 2) Blender 2.5 progress
* skejoe (n=skejoe@87.49.151.38) has joined #blendercoders
* kaito shamefully admits he had hardly the code time he wanted
<kaito> the ui widget code is far from ready, i have to redo the entire internal structure to make i
t work good
<kaito> new theme definitions, better button shape definition, callbacks for handling, that stuff
<kaito> and good hooks for the layout system
<kaito> it *seems* my schedule next week is quite empty tho, so i'll happily work on it further
* OgRo (n=ogro@c906eba8.virtua.com.br) has left #blendercoders ("Ex-Chat")
<joel_nl> speaking of Theme/UI looking at mfoxdogg's work on the render panels, there should be a
nice divider thingy for menu sections. (hope that makes sense )
<joel_nl> http://mfoxdogg.googlepages.com/tweaked_render_buttons.jpeg
<kaito> yesyes, all in the WIP section
<joel_nl> sorry ;)
<shul> whats the word on ops and python and contexts ?
<Moguri> Hey, the arrows are facing the right way :D
<kaito> brecht: you got updates?
<brecht> vekoon is adapting his blender API code
* KAHR-Alpha has quit (Read error: 104 (Connection reset by peer))
<brecht> we reviewed it and decided on some changes, to make it integrate better with RNA
<brecht> instead of duplicating some things
* slikdigit (n=slikdigi@blender/artist/slikdigit) has joined #blendercoders
<brecht> so, when that lands we can see how to converts operators to use it
* erwin_bullet (n=spam@c-98-234-112-166.hsd1.ca.comcast.net) has joined #blendercoders
<brecht> but that is not very high priority at the moment i think
<kaito> brecht: ok; and whats on your todo for next days/week?
* [a]drien has quit (Remote closed the connection)
<brecht> personally i'm working on getting UI code pluggable for python
* blendedSheep (n=sheep@host86-130-179-83.range86-130.btcentralplus.com) has joined #blenderCoders
* eyecandy (n=eyecandy@blender/artist/andy) has joined #blendercoders
<brecht> so python can register panels etc
<kaito> like what you did in buttons_object.c?
<kaito> ah i saw your proposal
<kaito> note that we should try to only use registered or RNA defined texts for ui
<brecht> further i'm working on some other RNA related things for the buttons
<kaito> to ensure we can get a simple translation system
<kaito> your first buttons code still uses hardcoded c labels
<brecht> i'm working on soft/hard range, animato keyframe for buttons, an RNA pointer button (e.g. o
bject parent)
<brecht> yes, the labels are an issue, it's related to RNA groups
<kaito> cool
* Metadave has quit ("Leaving")
<ideasman42__> brecht, kaito - can the UI own strings? - will help with python
<ideasman42__> (or did we agree on that at wintercamp?)
<kaito> who is "the UI" :)
<kaito> RNA owns strings for time being
<kaito> and for panels it's "the ui"?
<kaito> maybe for templates too
<ideasman42__> yep, but you might want to call an operator with certain options and have your own na
mes
<kaito> well; how would you translate that then
<kaito> would be nicest if such operator usage can generate own name
<theeth> kaito: the problem is that python will free the string when the script ends, so the ui draw
ing code will referenced free memory
<kaito> based on rna
<kaito> eh he's talking about py operators?
<theeth> no, py ui
<ideasman42__> about Py UI
<ideasman42__> if python draws a button or label
<kaito> ehh i dont see how this would be an issue if you just rna
* devroo (n=jandever@nb5.licanet.cz) has joined #blendercoders
<kaito> +use
<theeth> how do you use rna to draw a label?
<kaito> because its rna group or so
<kaito> we can make a label registry too, like for panels?
<ideasman42__> eh.? - seems overkill
<kaito> i rather first see the cases where using rna fails
<jwstolk> durian is all about overkill.
<kaito> because then the operator/rna spec fails too, and we could look at fixing it there
<brecht> if you never pass a string from python, there is no issue
<ideasman42__> operator button names cant be easily automatic
<brecht> if for some reason we have to anyway, we can definitely let the UI code own it
<kaito> further; i dont tallk about 'everything you want to do' but about 'what we will put in relea
se'
<ideasman42__> agree this should be an exception rather then a rule
<kaito> in the end people can mess around with own strings as much they want
<kaito> but thats not nice for us to release that i think
<ideasman42__> kaito, button names for operators are not that exceptional though - neither is a desc
riptive label
<kaito> sofar i named all operators with a button name
<kaito> and i think we also agreed on making ops as small as possible
<kaito> so if you define operator button as 'use property X set" it can just draw that as string nam
e in button
<kaito> "Extrude: Using Normal"
<kaito> or give the rest as a tooltip...
<ideasman42__> hrm. think this will be too in-practical in a lot of cases
<kaito> well; lets check on this with practical examples asap?
<ideasman42__> "Snap Cursor to Grid" vs "Snap Cursor: Target=Dird"
<ideasman42__> Grid*
<kaito> no meeting time needed for this now :)
<ideasman42__> no
* kaito wants to see a toolbar with properties work in shortest term
<kaito> its on my list right after the drawing code :)
<kaito> or in worst case i'll drop it on brechts desk!
<kaito> slightly 2.5 dev related: i've decided to move durian at least to after summer, to ensure i
got enough time for 2.5 work and siggraph
<kaito> and for siggraph the plans are this close -> <- to have a great booth again! :)
<theeth> joy!
* kaito really really wants to show off there
<Mystery> something hopefully related, with the new drawing code, would popups be possible?
<erwin_bullet> a booth?
<kaito> a giant one!
* Agiofws (n=agiofws@athedsl-430408.home.otenet.gr) has joined #blendercoders
<kaito> 20x30 feet island
* Agiofws has quit (Read error: 54 (Connection reset by peer))
<DingTo> hey erwin_bullet
<kaito> erwin_bullet: so make sure bullet is in shape then :)
<eyecandy> kaito: remember to have mini cds with blender and stuff for the booth :)
<erwin_bullet> sure, I will have OpenCL acceleration!
<DingTo> should we go on with 2.49?
* [Pitris] (n=petr@213-194-241-77-eth4-gwovo-user.802.cz) has joined #blendercoders
<kaito> we'll do free dvd handouts
<theeth> eyecandy: floppy with Blender on them!
<eyecandy> woot floppy!
<erwin_bullet> (AMD helped converting the CUDA stuff into OpenCL, which works cross platforms on CPU
and GPU)
<joel_nl> eyecandy: arent usb sticks better ?
<shul> kaito: maybe thumb drives with blender instead?
<eyecandy> joel_nl: but dvds you can use as frizzbees! :)
<ideasman42__> floppys say more, but were still at ~2.2mb
<shul> not all of the computers today have optical drives.. USB is more common
<kaito> shul: if you sponsor it
<shul> kaito: I'm sure its the same price as dvd
* pidhash has quit (Read error: 104 (Connection reset by peer))
<eyecandy> shul: *per* dvd?
<joel_nl> erwin_bullet: is that the same stuff i saw on the Khronos site ? the opencl physics ?
* shul don't have money, he lives with his gf in a tiny tiny apt
<theeth> shul: I seriously doubt it
<kaito> dvd repro is 20-30 cents or so
<eyecandy> isnt a dvd like 0,3 cents nowadays?
<shul> I'll have a look
<joel_nl> erwin_bullet: oops.. that was Havoc
<erwin_bullet> ah, Siggraph is in New Orleans?
<theeth> erwin_bullet: yup
* erwin_bullet remembers the good old days, 2001?
<kaito> 2000
<kaito> Nine Years Later :P
<erwin_bullet> Blender had a gigantic booth back then :)
<kaito> this time also gigantic, but low budget :)
<joel_nl> how low ?
<erwin_bullet> we work on some fracturing, it requires some tools...
<kaito> and no CEOs or marketing people!
<erwin_bullet> 'overhead' :)
* kaito suggests to go back to topic
<theeth> have the booth made of papier mache
<theeth> (and no booth hobos please)
<kaito> sig is august 3-7, and great target for working 2.5 demos, even when beta only
<ideasman42__> operator still need quite a bit of reworking, can make a list of todo's (or could jus
t do them)
<joel_nl> erwin_bullet: fracturing ?
<shul> found these guys http://www.ysspromo.com/14.html?sm=55397 but they don't answer...
<kaito> oh the poor homeless people in New Orleans...
<erwin_bullet> yes, fracturing rigid bodies into small parts, possibly pre-fractured in the 3d model
er, assigning strengths etc.
* artistxe (n=artistxe@173-86-12-233.dr01.wlbr.pa.frontiernet.net) has joined #blendercoders
<kaito> theeth: that was plan B, if we cant do booth :)
<theeth> lets hope it doesn't get to that :)
* kaito would love to see this zombie scene! :)
<andrecastelo> i'll buy the gamekit 2 to support a bigger booth
<joel_nl> erwin_bullet: have you read the paper of Matthias Müller ? "Real-Time Simulation of Def
ormation and Fracture
<joel_nl> of Stiff Materials"
<joel_nl> erwin_bullet: sory, will talk to you about this after meeting perhaps ?
<erwin_bullet> joel: probably.
* dfelinto (n=irchon@189.122.86.204) has joined #blendercoders
<DingTo> kaito: 2.49 ;-)
<elubie> shul: I'd like this one: http://www.ysspromo.com/m9_view_item.html?m9:item=237 ;)
* rocketmagnet (n=Miranda@chello084112185048.3.11.vie.surfer.at) has joined #blendercoders
Blender 2.49 status
* kaito has changed the topic to: Meeting time! 3) Blender 2.49 status
<erwin_bullet> Matthias is working for the competing PhysX sdk, and tries to patent whatever he can.
I promote open standards/implementations.
<DingTo> ok 2.49
<DingTo> i found a serious problem!
<DingTo> realtime softbodys, comparison 2.48a with Trunk: http://chronosom-studios.de/data/dingto/te
mp/softbody.ogv
* verblendet (n=verblend@p54B1BC7B.dip.t-dialin.net) has joined #blendercoders
<DingTo> i guess thats related to erwin_bullet s update
<DingTo> file: http://chronosom-studios.de/data/dingto/temp/softbody.blend
<erwin_bullet> .ogv?
<DingTo> ogg vorbis video
<DingTo> vlc plays it
* PapaSmurf (n=Roger@adsl-074-184-157-098.sip.asm.bellsouth.net) has joined #blendercoders
<shul> totem player can show it too
<shul> on my fc10
<dfelinto> erwin: se
* rush123 (n=rushyour@77-101-57-87.cable.ubr13.croy.blueyonder.co.uk) has joined #blendercoders
<erwin_bullet> let's not disrupt the meeting agenda.
<erwin_bullet> (either PM or use Bullet forums)
* dfelinto_ (n=dfelinto@189.122.86.204) has joined #blendercoders
<migius> ready for preview: patch for 2.49 - apply_matrix for negative scaled objects
<kaito> well if trunk has serious issues, we cannot do 2.49
<ideasman42__> erwin_bullet, theres also problem with bullet now having physics objects as dynamic e
ven if they are not set to this
<DingTo> indeed
<ideasman42__> (objects rotate when they used to not do this)
<migius> http://wiki.blender.org/index.php/User:Migius/orientation_matrix
<erwin_bullet> ideasman: do you have blend files for that?
<kaito> erwin_bullet: i guess you're around for helping to get 2.49 bullet options compatible to 2.4
8a?
<ideasman42__> erwin_bullet, nope but its very simple - like cube+plane
<erwin_bullet> sure, please let me know what the most urgent topics to fix are.
<dfelinto_> erwin_bullet: we need a nice doVersion. Did you read this email: http://lists.blender.or
g/pipermail/bf-committers/2009-March/022923.html
<kaito> hah erwin being swamped :)
* dfelinto has quit (Client Quit)
* dfelinto_ is now known as dfelinto
<kaito> you know erwin_bullet, "I wish you many users" :P
<erwin_bullet> can you file a bug in the game engine tracker, called Bullet 2.49a backwards compatib
ility with 2.48, and attach some .blend files with description?
<ideasman42__> erwin_bullet, just tested - make plane at some angle and scale up- set Cube as dynami
c- when it drops on the plane it rolls
<DingTo> i also suggest to do some more tests with texture nodes, tests and playing around with it i
ndicates that it doesnt work the same every time, i still have to investigate the specific problems
* Guest90993 has quit (Connection timed out)
<erwin_bullet> 'dynamic' instead of 'rigid body' ?
<ideasman42__> right
<ideasman42__> atm there is no difference
<dfelinto> erwin_bullet: it's there already :) http://projects.blender.org/tracker/?func=detail&aid=
18446&group_id=9&atid=127
<erwin_bullet> that sounds more like an integration bug, not in Bullet. I'll check it out, but perha
ps Benoit can help?
* charlie (n=charlie@cpc1-lutn5-0-0-cust184.lutn.cable.ntl.com) has joined #blendercoders
<ideasman42__> sure, but its an integration thats new since 2.48 ;)
* charlie is now known as Guest62034
<erwin_bullet> so we are discussing issues that pop up since 2.49a/latest trunk, compared to 2.48, r
ight?
<erwin_bullet> ideasman: I don't see the rotation problem mentioned in that tracker issue.
<ideasman42__> which issue?
<erwin_bullet> 'dynamic' not working
<ideasman42__> hrm, I didnt see an issue for this at all, just noticed while using the BGE
<erwin_bullet> can you add it all to this issue: http://projects.blender.org/tracker/?func=detail&a
id=18446&group_id=9&atid=127
<ideasman42__> anyway- bullet issues need to be resolved before release, can talk on the ML or track
er
<kaito> erwin_bullet: i've added this in notes for bf-committers too, point everyone at tracker for
bullet stuff
<erwin_bullet> what issues in short?
<erwin_bullet> damping, dynamic, pivot, those 3?
<ideasman42__> yep, think thats all
<erwin_bullet> damping already has a patch, it just has to be applied by me or Benoit, right?
<erwin_bullet> 'dynamic' should be a trivial patch, I'll check it out.
<dfelinto> erwin_bullet: kind of, we should patch it all at the same time to avoid a lot of do_versi
on
<ideasman42__> yeah that one should be applied right away, just the other 2 are unknown
<ideasman42__> I might have also broken softbody since it used to rely on welding verts at 0.1, but
I dont think this is the bug in the video
<erwin_bullet> ideasman: can you add a sample .blend for the soft body to that topic too?
* Rushmoom has quit (Remote closed the connection)
<erwin_bullet> we can expose the welding distance (0.1) to the soft body 'advanced' settings if need
ed
<ideasman42__> erwin_bullet, I changed physics mesh creation not to do welding
<erwin_bullet> it needs welding probably.
<ideasman42__> its really slow
<erwin_bullet> we can make it faster
<erwin_bullet> it needs welding, can you change it back?
<ideasman42__> maybe, but I think we should look into better solutuion
<erwin_bullet> 'make it faster' is the solution
<ideasman42__> eg - welding optional or a post-process
<ideasman42__> DingTo, can you make a softbody example? a tracker report
<theeth> ideasman42__: in the mean time, revert it
<ideasman42__> theeth, which?
<erwin_bullet> please report in the same issue:
<erwin_bullet> http://projects.blender.org/tracker/?func=detail&aid=18446&group_id=9&atid=127
<theeth> your commit that removed weilding
<vekoon> hey there
<ideasman42__> theeth, Id rather not
<DingTo> ideasman42__: sure
<theeth> an optimization that breaks thing is no no
<vekoon> ouch, missed 2.5 progress
<ideasman42__> theeth, relying on remove doubles is not good either
<erwin_bullet> indeed, please revert back.
* Fweeb_afk is now known as Fweeb
<theeth> ideasman42__: either you do it or someone else does
<ideasman42__> cyborg_ar had a scene that took over 30sec to load
<ideasman42__> now ~4
<theeth> like erwin said, that's not the solution
<erwin_bullet> we could do only welding for soft bodies, not for other objects.
<erwin_bullet> we have to check it, but simply removing welding breaks too many things
<shul> vekoon: as for 2.5, I understand brecht is waiting for u
<kaito> ok... bullet issues clear?
<erwin_bullet> ideasman: I'll look into a faster welding method
<erwin_bullet> kaito: hope so, yes.
<vekoon> shul: yeah I'm integrating my API code into RNA
<vekoon> it's some bit of works right there
<ideasman42__> erwin_bullet, could it be a post-process? - like blenders remove doubles is not that
slow
<ideasman42__> rather then remove doubles when adding each face
<erwin_bullet> ideasman: actually, it is some stupid implementation of adding triangles: we can prev
ent doubles in the first place, no need to 'remove them' afterwards.
<kaito> i can email to bf-committers to consider trunk really feature-frozen now, no new stuff, only
finishing what's there and bugfixes
<erwin_bullet> ideasman: post process?
* sausages (n=jay@cpe-66-67-48-185.rochester.res.rr.com) has left #blendercoders
<kaito> pre process probably :)
<ideasman42__> erwin_bullet, its using blenders original verts so only case remove doubles is needed
is where uses split off verts and expected them to act connected
<ideasman42__> or high poly softbody with verts closer then 0.1
<erwin_bullet> ideasman: problem is that user can flag triangles as non-colliding, so we need at lea
st a new index array
<ideasman42__> erwin_bullet, it deals with this
<erwin_bullet> ideasman: we can add a setting for that 0.1 value
<dfelinto> kaito: trunk feature-frozen? Should I commit BGE dome code then? (easy to revert later if
it's not good) though I would rather some review first.
<erwin_bullet> ideasman: so what is the problem exactly?
<theeth> dfelinto: keep it in branch for review
<kaito> dfelinto: how certain are you for this?
<ideasman42__> erwin_bullet, just saying that its not removing doubles anymore
<ideasman42__> in most cases it wont need to - except for the softbody case
<erwin_bullet> does the BGE dome code touch a lot of files? better keep it in a branch I would say.
<theeth> dfelinto: dome code has been worked on for a while, it's not a "new" feature
<erwin_bullet> ideasman: can we leave the original path, for soft bodies?
<dfelinto> theeth: ok I got it.
<ideasman42__> erwin_bullet, can add an option that allows remove doubles?
<kaito> dfelinto: what is your proposal? need review and commit in trunk?
<theeth> ideasman42__: just do it all the time when the object is softbody
<erwin_bullet> ideasman: to be backwards compatible, doing a special case for soft bodies is easier.
<ideasman42__> yeah but 0.1 is a bit dumb too
<kaito> dfelinto: if in doubt, its good off in branch too :)
<dfelinto> kaito: this is my proposal: http://lists.blender.org/pipermail/bf-committers/2009-March/0
22962.html It needs review
* Tr3B has quit (Read error: 110 (Connection timed out))
<kaito> dfelinto: after all, the handful of dome users can make own build or compile self
<erwin_bullet> 0.1 can be exposed in the advanced soft body GUI
<ideasman42__> can do this in a way that loads old files ofcourse
* Tr3B (n=trebor@p548B5EF2.dip.t-dialin.net) has joined #blendercoders
<DingTo> ideasman42__: ok done: https://projects.blender.org/tracker/index.php?func=detail&aid=18470
&group_id=9&atid=125
<dfelinto> kaito: that's true. But IMHO it's an elegant hook. It doesn't affect BGE performance at a
ll.
<kaito> dfelinto: eh 'share own build or compile'
<erwin_bullet> ideasman: we need removal of doubles by default for soft bodies, with a threshold (0.
1) that can be changed in the advanced settings of soft body.
<ideasman42__> erwin_bullet, yep
* Rapp has quit (Read error: 110 (Connection timed out))
<kaito> dfelinto: i'd say, if you get ben2610 agreeing on it, it can go in trunk :)
<ideasman42__> but DingTo's bug report I think is not related to my commit
<erwin_bullet> dfelinto: let ben2610 do the commit, you provide the patch
<dfelinto> kaito: that's what I've been working on :) he agreed with the general design already. but
I think he never saw the code.
<kaito> oki
<Moguri> Oh, oops, 2.49 status :s
* kaito suggests to move on now
<migius> there is a patch for 2.49, waiting for review (theeth did it already): apply_matrix (=matri
x2scale+matrix2euler) for negative scaled objects
<migius> http://wiki.blender.org/index.php/User:Migius/orientation_matrix
<elubie> dfelinto: you think dome could be 2.49 target still? In this case review soon is probably g
ood. But if the relevant people agree it could still be merged at a later stage from branch
<dfelinto> elubie: it certainly could be target to 2.49 IMO.
<brecht> migius, did you test the functionality that uses these functions?
<brecht> this seems really quite a risky change for 2.49
<theeth> brecht: IIRC, a lot of stuff is already broken when dealing with negative scale
<migius> i tested on objects, but not on armatures yet
<kaito> migius: your preposition is also not true (Blender orientation-matrix is an orthogonal_matri
x. Applying non-orthogonal-matrix (e.g. shear-matrix) doesn't work - it is on-the-fly transformed in
to orthogonal-matrix, so some information is lost or corrupted.)
<kaito> parenting or constraints will allow
<migius> nobody is perfect :)
<migius> i know
<migius> but not as original matrix
<kaito> further; the obmat is readonly for python imho
<dfelinto> elubie: but as I said in the email, it's the first time I coded so many lines. It works b
ut I can't make sure it's a polished code. But I can work that in off, bogging brecht and ben2610 fo
r a review if they have time.
<ideasman42__> kaito, nope
<kaito> but thats another topic :)
<ideasman42__> :)
<kaito> i mean *should* :)
<elubie> dfelinto: that's fine, just keep poking people for review ;)
* kaito will make sure its not in 2.5! or kick it out!
<ideasman42__> cool!
<ideasman42__> kick it away
<theeth> dfelinto: I asked ben2610 earlier in meeting, he said he should review it
<migius> kaito: apply_matrix doesnt write to matrix, only represent in euler and scales
<brecht> migius, before change is applied it definitely needs to be tested with armatures, keyframin
g, constraints, ..
<dfelinto> theeth: that's great. Thanks a lot Martin !
<kaito> dfelinto: thank ben!
<ben2610> migius: about this subject: there is an incompatibility between Blender and the BGE w/ reg
ards to matrix
<theeth> yes, thanks ben2610
<kaito> :)
<theeth> I just mastered the skill of poking people
<migius> brecht: who can check it competent?
<theeth> kaito: which reminds me, about those modal operator keymaps... ;)
<kaito> ouch!
<migius> i have no/little experience with armatures
<kaito> that stick gets sharper every week!
<migius> ben2610: could you point me to this issue?
<ben2610> migius: the BGE only supports uniform scaling *except* for the leaf object in a Parent-chi
ld chain. If there is a non-uniform scaling in between, the result differ in Blender and the BGE
<shul> kaito: quickly: how many USB memory would u need for sigraph ?
<ben2610> this is because the BGE treats scaling independently to the rotation while blender combine
s both
<migius> ben2610: interesting
<kaito> shul: no idea, at least a gig?
<theeth> ben2610: yeah, students had lots of problems with that in the blender class I give at uni
<shul> no, I mean how many, not what size..
<ben2610> the separation of scaling is a requirement of Bullet and IMO much cleaner that what Blende
r is doing
<migius> look at my proposal for inverse matrix: http://wiki.blender.org/index.php/User:Migius/orien
tation_matrix
<migius> ben2610: ^^
<kaito> migius: we can come back to your proposal outside of meetings
<kaito> or mailing list
<migius> kaito: ok
<theeth> ben2610: would it be possible to make the blender->ge conversion fix that (not asking if yo
u'll do it, just if it's possible)?
<kaito> best is to stick to defining actions in meetings, not reviewing/discussing too much
<theeth> kaito: his proposal is already on the mailing list
<kaito> yep. but no discussion :)
<kaito> maybe its too hard to grasp...
<migius> kaito: i would like to now, who can help to check the dependencies of this patch
<erwin_bullet> migius: this patch is for after 2.49, right?
<kaito> migius: i don't do python... and work on 2.5 now :)
<migius> erwin_bullet: it is for 2.48
<erwin_bullet> ? back in time?
<migius> *2.49 too
<migius> :)
<kaito> if you change math so much migius, you might better name the function differently to not bre
ak stuff
<DingTo> i guess he developed it for 2.48
* dfelinto has quit ("+ sleep = +rest = +happiness")
<migius> it is bugfix!!! not patch
<erwin_bullet> migius: it could potentially break more then it fixes.
<theeth> kaito: IIRC, the function is broken for negative scale already, this is a fix
<kaito> http://wiki.blender.org/uploads/0/06/Orientation_matrix_arithb_c_patch.txt
<kaito> ok so this is all?
<brecht> maybe it is broken, but i would be surprised if other functions compensate for it
<theeth> unless somebody can vouch for all the cases that function is used and say the fix doesn't b
reak things more than it currently is, I think it might be better to put that in 2.5
<brecht> *would not be
<migius> erwin_bullet: i know the risk, but it is realtively small, Existing routine produce error r
esults, so what
* kaito thought it was a py thing
<ideasman42__> not a py thing
<erwin_bullet> migius: as long as it doesn't break any BGE features, I'll leave the complaining to o
thers :)
<Moguri> ben2610: ideasman42__: andrecastelo: Are we meeting after the meeting for bge api again?
<ideasman42__> but I have had this problem before and current results are problematic too
<andrecastelo> sure
<ben2610> Moguri: ok
<kaito> migius: ok; a good reliable matrix -> size/eul is very good to have, but my guts tell me its
better to make it a new function, and insert it only on places you know will work with it well
<ideasman42__> cant this be tested with some complex blendfiles to prove it works ok? - then let use
rs do the rest
<kaito> i recall code in blender assumes a failing mat-to-eul/size
* joeghi (n=ghibo@host50-32-dynamic.40-79-r.retail.telecomitalia.it) has joined #blendercoders
* Received a DCC CHAT offer from joeghi
<migius> kaito: or i check all dependencies (listed in my proposal with doxygen)
<kaito> migius: yep thats very nice :)
* DCC CHAT connection established to joeghi [79.40.32.50:48509]
<kaito> but it makes it still work to check each
<migius> i have prepared a blend file for intensive tests
<erwin_bullet> migius: can you also test all the BGE regression tests?
<kaito> let me phrase it this way then: i will love to check it, like in june or later
<migius> yes, i will try
<kaito> this is too much to 'just do and see'
<elubie> migius: I think the suggestion to write new function and name it diffenrently is a good ide
a. Then one by one go through the dependencies, replace and test smaller area until confirmed it wor
ks
<kaito> put in patch tracker and assign to me?
<migius> elubie: a part is tested alredy, and works
<kaito> i'm quite familiar with all code on blender side that uses this
<migius> kaito: reported in bugtracker
* kaito proposes to move on
<DingTo> +1 lets do GsoC
<kaito> migius: its really cool to have this fix, but i hope you understand to not include it withou
t using a bit of attention for it, and i just cant do this right now
<migius> totaly agree
<kaito> i always wanted a good function for this, so i know where to look, but it can take hours to
validate that
GSoC
* kaito has changed the topic to: Meeting time! 4) GSoC
<kaito> of course others can also do it if he/she feels like it :)
<kaito> ok the soccers!
<theeth> 7 proposals are in
* kazanbas_away is working on the "Integrating Rigid Body Physics With Animation System" proposal
<kaito> 7 via google site?
<theeth> yes
<kaito> not much
* andrecastelo is working in a 2.5 proposal
<theeth> and ali hasn't submitted anything yet
<kaito> but i guess its not yet with all fake ones :)
<kaito> last days we usually get desperate attempts :)
<theeth> I think the system is better at preventing spam this year
<joeghi> rigid body -> rigor mortis? ;-)
<kaito> what ive seen sofar, the proposals are well prepared
<theeth> gsoc mentors should definitely give feedback on proposals BEFORE deadline
<theeth> especially if they are missing details
<andrecastelo> who is the appointed mentor for the 2.5 ideas?
<theeth> (especially schedule and mini milestones)
<theeth> andrecastelo: there's no appointed mentor yet
* kaito has people mailing me personally with soc proposals even, but i shoo them away :)
* gustavg (n=gustavg@kerojip.med.sgsnet.se) has joined #blendercoders
<kaito> i'll add a big note in minutes for all soc mentors to check the proposals asap
<theeth> there's not that many days left
<kaito> until friday?
<theeth> I think so
<andrecastelo> should I send the proposal directly to the web app or to the mailing list first?
<joel_nl> someone should make a proposal on fracturing meshes ;)
<ben2610> are there proposals for the BGE?
<theeth> not yet
<theeth> ben2610: did you register as a mentor?
<ben2610> theeth: I did. Did we put some ideas in the wiki?
<theeth> don't know
<ben2610> we discussed things last week but don't know if they went to the ideas page
<brecht> andrecastelo, maybe do both if you want to get the most feedback
<theeth> the proposals in the gsoc app are there: http://socghop.appspot.com/org/list_proposals/goog
le/gsoc2009/blender
<brecht> you can still edit it in the web app i think?
<theeth> brecht: yup
<andrecastelo> should i bother the 2.5 taskforce mailing list too?
<theeth> just committers should be ok
<kaito> bf-committers
<theeth> people on 2.5 ml are on committers too
<andrecastelo> okay
<theeth> (people that matter at least)
* ZanQdo (n=ZanQdo@201.201.2.22) has joined #blendercoders
* espace (n=espace@72.155.197-77.rev.gaoland.net) has joined #blendercoders
<erwin_bullet> joel_nl: fracturing meshes and convex decomposition would be very useful for rigid bo
dy dynamics/Bullet/BGE
<kaito> http://imbusy.org/ <- he sent me gsoc proposal
* eyecandy has quit (Remote closed the connection)
<theeth> someone from the demo scene, cool
<joel_nl> erwin_bullet: there is a script that fractures meshes using boolean actions, the same one
as posted in the bullet forum, but it's not realistic
<kaito> for VBO support in blender
<theeth> kaito: it's in the gsoc app
<elubie> kaito: he put that on the google site already
<theeth> http://socghop.appspot.com/student_proposal/review/google/gsoc2009/imbusy/t123827843969
<kaito> ah lukas
<kaito> ok :)
<erwin_bullet> joel_nl: it could be a starting point, it can be improved in various ways. I could me
ntor, if there is a serious proposal.
<kaito> any GSoC student who wants to use meeting time to get feedback or someone assigned to look a
t things?
<joel_nl> erwin_bullet: it should be pretty do-able, take a look at the papers i've PM'd you. the
methods used arent anyting new.
<erwin_bullet> joel: it's ok, I know the papers, and assigned some collegue in doing research in thi
s.
<andrecastelo> kaito: well, I'm going to expand the APIfication idea
* DingTo (n=DingTo@p5B2FA769.dip0.t-ipconnect.de) has left #blendercoders
<andrecastelo> i'm going to look into code, study the operators and rna
<kaito> andrecastelo: you mean help with 2.5
<kaito> ok
<erwin_bullet> joel: we have some meetings with O'Brien sometimes, he lives in the Bay area too.
<yukishiro> I put my app on google too.
<andrecastelo> probably later today i'll come up with a decent proposal
<yukishiro> kaito and broken have looked at it.
<andrecastelo> kaito: yeah, help with 2.5
<kaito> andrecastelo: use this channel for feedback any time
<andrecastelo> okay, thanks :)
<kaito> tomorrow and days after most are hanging out here anyway
<joel_nl> erwin_bullet: what are your thoughts on this ? convert meshes to tetrahedons like the g
uys from starwars do, or use some sort of boolean ?
<theeth> yukishiro: which one is yours? Light Paint?
<yukishiro> theeth: yes
* joel_nl has quit (Read error: 54 (Connection reset by peer))
<kaito> yukishiro: is there a bug in gsochop app truncating lines badly?
<theeth> proposal is ok, schedule and everything, enough details
<erwin_bullet> joel: starward/Pixelux does FEM, we meet with them regularly too.
* joel_nl (n=chatzill@195-241-118-50.ip.telfort.nl) has joined #blendercoders
* ianwill (n=ianwill@189-46-73-156.dsl.telesp.net.br) has joined #blendercoders
<yukishiro> possibly. I formatted mine in vim, and google adds line breaks to it again..
<joel_nl> erwin_bullet: pixelux DMM i mean\
<theeth> kaito: the app line wraps a lot
<erwin_bullet> pixelux DMM = FEM, they had a presentation at GDC, last week.
<kaito> yeez, google coders :)
<theeth> kaito: he has a pdf link at the bottom
<joel_nl> erwin_bullet: FEM ?
<yukishiro> theeth: I'm a girl. :-)
<kaito> yukishiro: it seems you've nicely amended the proposal based on the review :)
<erwin_bullet> joel:PM
<Moguri> ben2610: All of your macros so far have been KX_PYATTRIBUTE_TYPE_RO/RW, the function one is
backwards :s
<kaito> cool! more girl power in blender! :)
<theeth> yukishiro: appologies, it's hard to know online :)
<yukishiro> kaito: I still have some ideas and I hope I can refine my proposal a bit more next week.
<kaito> soon we guys are only needed to dig holes or mow lawns :/
<yukishiro> theeth: no worries.
<theeth> yukishiro: all in all, the proposal is solid and we usually had good experience with grad s
tudents
<theeth> they tend to get busy when gsoc is offer, but we can deal with that
<yukishiro> theeth: that's good to know. :-)
<kaito> oki
<theeth> mind you, we don't know how many slots we have in advance, so nothing is fixed yet
<theeth> kaito: how many slots did we have last year? 3?
<kaito> i suggest to close meeting now, and go back chatting random topics :)
<kaito> 6
<theeth> really
<kaito> but with 20+ or so submissions
<kaito> of which most was crap
<kaito> so we got what we asked for
<yukishiro> yeah. this year google doesn't provide many openings.
<theeth> ha, but we failed some at mid term, that's why I don't recall 6 finished projects
<kaito> 5 were completed
* kaito has changed the topic to: Sunday meetings 16h CEST, 14h UTC | please add a topic you would l
ike to be discussed at http://wiki.blender.org/index.php/Dev:SundayMeetingAgenda
