--- Log opened Sun Jan 20 00:00:30 2008
00:33 -!- timonator [n=timonato@cl-2290.ham-01.de.sixxs.net] has quit [Remote closed the connection]
00:33 -!- timonator [n=timonato@cl-2290.ham-01.de.sixxs.net] has joined #synfig
01:10 -!- genete [n=Genete@84.122.45.30.dyn.user.ono.com] has joined #synfig
01:34 < dooglus> hi genete 
01:34 < genete> hi dooglus 
01:34 < genete> long log but catched up ...
01:34 < dooglus> good
01:34 < dooglus> did you see pacman?  :)
01:34 < genete> he he pacman....
01:35 < genete> yes 
01:35 < genete> it is related with a bug I reported
01:35 < dooglus> ok
01:35 < dooglus> it's at least 2 bugs so far
01:35 < dooglus> I'm working on it
01:35 < genete> good
01:35 < genete> I've improved a little the particles layer
01:35 < genete> ooops 
01:36 < genete> the particle template ... ( I was dreaming...)
01:36 < dooglus> :)
01:36 < genete> and have set the amount = 0 when particles are off
01:36 < genete> it accellerates rendering a lot! =)
01:36 < dooglus> ok
01:37 < genete> also working on a fireworks sample using particles.
01:38 < dooglus> cool :)
01:38 < genete> no any sample yet
01:38 < genete> becasue render time is awful
01:38 < genete> due to the amount of nested particles...
01:39 < genete> I would like to make a firework festival with "Synfig" word for the end of the demo reel
01:39 < genete> Im sure pxegeek will love it!
01:40 < dooglus> each firework can be a particle, and have a nested particle for when it explodes?
01:40 < genete> something like that
01:40 < genete> but it have different solutions and not sure what's better
01:40 < genete> also want a final festival with lots of explosions... so hard to render
01:50 < genete> the problem is that I only use a 20% of the paritcles and the rest of the time the particles are rendered so far away. I'll include the amount=0 trick and it would speed up the particles render.
01:51 < dooglus> are they really rendered?
01:51 < dooglus> or just have their position calculated?
01:51 < genete> when amount =0 not
01:52 < genete> the only way I've found to set particles on/off properly is place them far away inside its time loop and random tricks
01:52 < genete> then I've added the amount = 0 when particles are off and it speed ups a lot
01:52 < genete> but need to redo fireworks with that new template.
01:53 < genete> I'll show you a bout 4 seconds of first attempt of fire works with the old template.
01:53 < dooglus> ok
01:53 < genete> it takes ages to render becasue I need 400 particles each time and only see 20% of them more or less
01:55 < genete> I have also a linear gradient as background that I believe it slow down a lot the render time...
01:57 < dooglus> yes, maybe, although it should only be rendered once per frame
01:58 < dooglus> try disabling it and seeing what difference it makes
01:58 < genete> the gradient is outside duplicate scope
01:59 < genete> but when particles are rendered at a 2000000 distance then the canvas needed or calculated is huge
01:59 < genete> that's what I believe it is so slow
02:00 < genete> when you render something outside the canvas size it takes time, why?
02:00 < genete> if all the bounding rectangle is outside, why to render it?
02:04 < dooglus> this is the last remaining problem on the wiki dup layer page?
02:04 < dooglus> dup layer isn't smart about bounding boxes
02:04 < genete> I don't know if it only related to dup layer
02:05 < genete> draw a buch of circles (make its position to random and duplicate them manually) 
02:05 < dooglus> see if you can find a simple example - where rendering off-canvas at -10,-10 is quick, and at -10000,-10000 is slow - or similar
02:05 < genete> encapsulate them and translate to 1000, 1000
02:05 < genete> and render and see what happen
02:06 < dooglus> ok
02:06 < dooglus> the encap layer has had a few bugs about bounding boxes re. offsets
02:06 < dooglus> I wouldn't be surprised if it's still wrong
02:07 < genete> place to 100000, 100000 better 
02:07 -!- pxegeek [n=chatzill@c-71-59-140-184.hsd1.or.comcast.net] has joined #synfig
02:07 < genete> I'm sure that the bounding box don't touch the canvas
02:08 < dooglus> I think http://dooglus.rincevent.net/synfig/eggs.html was related - svn r260!
02:08 < genete> wow whan you were a child! ;)
02:09 < dooglus> yes, before my hair started growing
02:10 < genete> dooglus: it is only related to dup layer
02:10 < genete> I've done the recipe avobe and it is fine
02:10 < dooglus> the patch was:
02:11 < dooglus> ... apparently impossible to copy/paste out of gitk :)
02:11 < dooglus> ... but related to bounding rectangles and the pastecanvas origin
02:11 < dooglus> I'm going to sleep - it's gone 2am dontcha know?  :)
02:12 < dooglus> later...
02:12 < genete> right me too
02:12 < genete> night
02:12 < genete> bye
02:17 < pxegeek> 'night you two!
02:17 < genete> http://www.darthfurby.com/genete/synfig/fireworks-show.avi
02:17 < genete> hope you like it pxegeek !
02:18  * pxegeek still catching up on logs - I'll check it out
02:18 < genete> It is my proposed end of synfig demo reel
02:21 -!- timonator [n=timonato@cl-2290.ham-01.de.sixxs.net] has quit [Read error: 110 (Connection timed out)]
02:23 < genete> bye
02:23 -!- genete [n=Genete@84.122.45.30.dyn.user.ono.com] has quit ["Abandonando"]
02:46  * factor save genete's avi for later viewing
02:51 -!- Yoyobuae [n=quete@201.224.135.156] has joined #synfig
02:51 -!- timonator [n=timonato@cl-2290.ham-01.de.sixxs.net] has joined #synfig
03:11 -!- timonator [n=timonato@cl-2290.ham-01.de.sixxs.net] has quit [Read error: 104 (Connection reset by peer)]
03:16 -!- timonator [n=timonato@cl-2290.ham-01.de.sixxs.net] has joined #synfig
03:21 -!- Yoyobuae [n=quete@201.224.135.156] has quit []
06:15 -!- pxegeek [n=chatzill@c-71-59-140-184.hsd1.or.comcast.net] has quit [Read error: 113 (No route to host)]
06:31 -!- pabs3 [i=pabs@d122-104-115-97.per9.wa.optusnet.com.au] has joined #synfig
06:57 < pabs3> hmm http://synfig.org/Drawing_a_Rectangle_based_on_Width_and_Height looks like something for the tips page
08:07 -!- omry [n=omry@bzq-84-108-20-56.cablep.bezeqint.net] has quit ["Leaving"]
10:23 -!- pabs3 [i=pabs@d122-104-115-97.per9.wa.optusnet.com.au] has quit [Read error: 104 (Connection reset by peer)]
10:34 -!- pabs3 [i=pabs@d122-104-115-97.per9.wa.optusnet.com.au] has joined #synfig
10:47 -!- pabs3 [i=pabs@d122-104-115-97.per9.wa.optusnet.com.au] has quit [Read error: 104 (Connection reset by peer)]
10:51 -!- pabs3 [i=pabs@d122-104-115-97.per9.wa.optusnet.com.au] has joined #synfig
12:16 -!- pabspabspabs [n=pabs@d122-104-115-97.per9.wa.optusnet.com.au] has joined #synfig
12:16 -!- pabs3 [i=pabs@d122-104-115-97.per9.wa.optusnet.com.au] has quit [Read error: 110 (Connection timed out)]
12:28 -!- pabspabspabs is now known as pabs3
12:38 -!- Zelgadis [n=zelgadis@87.103.170.242] has joined #synfig
13:01 -!- Zelgadis [n=zelgadis@87.103.170.242] has quit ["Leaving."]
13:23 -!- Zelgadis [n=zelgadis@87.103.170.242] has joined #synfig
13:23 -!- Zelgadis [n=zelgadis@87.103.170.242] has quit [Remote closed the connection]
13:24 -!- Zelgadis [n=zelgadis@87.103.170.242] has joined #synfig
13:28 -!- Zelgadis [n=zelgadis@87.103.170.242] has quit [Client Quit]
13:42 -!- Zelgadis [n=zelgadis@87.103.170.242] has joined #synfig
13:46  * dooglus is having trouble with the 'Straight' blend method
13:47 < dooglus> looks like most of the layers will need changing to get it to work how I imagine it should work
13:47 < Zelgadis> Strange, why #synfig channel is not logged anymore?
13:47 < dooglus> Zelgadis: I log it; the official logging bot seems to come and go at random
13:47 < dooglus> Zelgadis: http://dooglus.rincevent.net/synfig/logs/2008/?C=M;O=D
13:49 < Zelgadis> dooglus: Wow! I don't knew it...
13:50 < Zelgadis> dooglus: it seems, what official bot resting since 2008-01-17
13:50 < dooglus> Zelgadis: I think maybe he works 2 different jobs
13:50 < dooglus> Zelgadis: he's probably moonlighting for #blender or something
13:51 < pabs3> :)
13:51  * pabs3 pinged darco about it this morning
13:51 < dooglus> never phones in sick, just turns up out of the blue and expects us to be all impressed with his coloured highlighting
13:52 < pabs3> Zelgadis: dooglus' logs are linked from the communication page
13:52 < dooglus> pabs3: is there some way we can get wiki.synfig.org to work as an alias for synfig.org?
13:53 < dooglus> pabs3: actually, I guess that's not important - forget it :)
13:53 < pabs3> I think disabling the redirect and adding a ServerAlias would do it, why?
13:55 < dooglus> pabs3: I am in the habit of type "wik" into the firefox address bar and having it list the synfig wiki pages I visit most often
13:55 < dooglus> pabs3: having a unique prefix makes it easier to access pages from the history in that way
13:55 < dooglus> I guess I can get used to typing 'syn' instead
13:57 < dooglus> I'm wondering what to do about the "Straight" blend method ( http://synfig.org/Blend_Method#Straight )
13:57 < dooglus> it doesn't work as described - so what should be changed?  the description or the code?
13:58 < pabs3> yah, I have that same habit :)
13:58 < pabs3> it used to work that way?
13:59 < dooglus> it kind of works that way
14:00 < dooglus> but that depends whether it's using the tile renderer or not, and whether the amount is 1.0 or 0.999, and whether the layers are encapsulated or not...
14:01 < pabs3> sounds complicated
14:01 < dooglus> look at the 'japan' example
14:01 < dooglus> the red circle is 'straight' blended with amount 1.0
14:02 < dooglus> according to the wiki, the stripes shouldn't be visible at all - 'straight' with amount 1.0 hides all other layers
14:06 < dooglus> if I encapsulate the circle and set the encap layer's blend to 'composite', then it does hide the stripes
14:06 < dooglus> (until you zoom in)
14:10 < pabs3> the code says this (seems to match the wiki): Straight linear interpolation from A->B (Alpha ignored)
14:11 < pabs3> I recon the zoom thing sounds like a bug
14:12 < pabs3> not sure why the stripes shouldn't be visible
14:13 -!- _dojo [n=dojo@mgdb-4db85ebd.pool.einsundeins.de] has joined #synfig
14:13 < _dojo> hi
14:13 < pabs3> hi _dojo 
14:14 < _dojo> i have a question: how can a close a bline?
14:15 < pabs3> dooglus: encap thing doesn't hide the stripes for me
14:15 < pabs3> http://synfig.org/How_do_I#Close_a_bline.3F
14:15 < pabs3> _dojo: ^^
14:16 < _dojo> thx
14:16 < _dojo> i think it was so easy, that i cann't find it ^^
14:17 < pabs3> dooglus: ah, I see, you meant straight on the encap layer - that is freaky
14:19 < dooglus> pabs3: if the circle is Straight and A=1 then only the circle should show, right?
14:20 < dooglus> pabs3: Straight is a blend method which can be used to fade from "just the stuff behind" (at A=0) to "just this layer" (at A=1)
14:22 < pabs3> hmm, I guess that the circle only affects stuff under it rather than the whole canvas?
14:23 < dooglus> pabs3: the circle layer doesn't touch any of the pixels which aren't part of the circle
14:24 < dooglus> the same goes for pretty much all the other layers too, though
14:25 < dooglus> I'm thinking that rather than fix each layer individually to know about what 'straight' blending is, I can have a new 'encap' layer placed around each non-encap layer that uses straight blending
14:26 < dooglus> (and then, of course, none of the examples will render nicely - but they will at least render correctly :) )
14:33 < pabs3> not sure I understand the problem
14:39 < dooglus> all the examples use the 'straght' blend method
14:39 < factor> out
14:39 -!- factor [n=factor@ip68-14-160-70.ok.ok.cox.net] has left #synfig ["Ex-Chat"]
14:39 < dooglus> and rely on it not working!
14:39 < dooglus> like the japan one.  if 'straight' worked properly, the stripes wouldn't be displayed...
14:42 < pabs3> I think I need to sleep, still not understanding how it isn't working
14:42  * pabs3 bbl
14:42 < dooglus> ha, ok
14:42 < dooglus> sweet dreams :)
16:20 -!- AkhIL [n=AkhIL@90.188.221.229] has quit [Read error: 104 (Connection reset by peer)]
16:34 -!- _dojo [n=dojo@mgdb-4db85ebd.pool.einsundeins.de] has quit [Remote closed the connection]
16:48 -!- MangoFusion [n=jamesu@host81-132-118-101.range81-132.btcentralplus.com] has joined #synfig
16:49 -!- AkhIL [n=AkhIL@90.188.221.229] has joined #synfig
16:56 < MangoFusion> hey there!
17:22 < Zelgadis> ???
17:42 -!- Zelgadis [n=zelgadis@87.103.170.242] has quit ["Leaving."]
20:03 -!- MangoFusion [n=jamesu@host81-132-118-101.range81-132.btcentralplus.com] has quit []
20:13 -!- MangoFusion [n=jamesu@host81-132-118-101.range81-132.btcentralplus.com] has joined #synfig
20:43 -!- pxegeek [n=chatzill@c-71-59-140-184.hsd1.or.comcast.net] has joined #synfig
21:02 -!- genete [n=Genete@84.122.45.30.dyn.user.ono.com] has joined #synfig
21:03 -!- dojo [n=dojo@mgdb-4db8d426.pool.einsundeins.de] has joined #synfig
21:03 < dojo> hi
21:04 < genete> hi dojo
21:05 < dojo> a question: i want to link two ducks, but they will not be at the same position, one of them "jump"
21:05 < genete> dojo: right. If you link it both should have same value
21:06 < dojo> velue?
21:06 < genete> vAlue
21:07 < dojo> sry, my english is bad, so what is about the value?
21:08 < genete> every duck represent a parameter of the layer. It holds a parameter's value 
21:09 < dojo> both are verteces of two different bspline
21:09 < genete> ok. So when you link them they have same position/value
21:10 < genete> read this to understand why one is moving and not the other: http://synfig.org/Linking
21:11 < dojo> i read it already, but i don't find the reason of the "jumping"
21:13 < genete> when you link two values or two parameters they are the same. If they are using the same relative value to the origin of coordinates they are at the same postions.
21:14 < genete> Before link they are at different positions so after link one of them should "jump" to match the position of the other. The decision of who jumps is given at that wiki page 
21:16 < dojo> jes, it _should_ "jump" to match the position of the other, but it jumps to another position and than there is a padding between them
21:17 < genete> ah! you didn't mention that.
21:17 < genete> that's due to a mismatch of their origins. Select both origins and link them. 
21:17 < genete> The origin is a green duck usually at the center of the window.
21:18 < genete> Alternatively set both origin parameters to the same value
21:18 < dojo> thx a lot !!!!
21:18 < genete> (but you could unintentionatelly move one of them)
21:19 < dojo> sorry, i don't understand what you mean
21:20 < genete> I mean that if you don't link them you can grab one of them and place it separated of the other Origin duck. Better to link instead of simply set them the same value manually
21:21 < dojo> okay, i linked them, but i think it works too
21:24 < dojo> i new question: how can i "transport" colors from one button to another
21:33 -!- dojo [n=dojo@mgdb-4db8d426.pool.einsundeins.de] has quit [Remote closed the connection]
21:51 -!- MangoFusion [n=jamesu@host81-132-118-101.range81-132.btcentralplus.com] has quit []
21:55 -!- MangoFusion [n=jamesu@host81-132-118-101.range81-132.btcentralplus.com] has joined #synfig
22:18 -!- ulrik [n=ulrikbod@213-65-95-57-no42.tbcn.telia.com] has joined #synfig
22:19 < ulrik> Hi everybody!
22:19 < genete> hi ulrik! I'm glad to see you again here!
22:19 < ulrik> pxegeek: nice work with the demo reel
22:19 < ulrik> hi genete!
22:19 < ulrik> how are you?
22:20 < genete> so fine, and you?
22:20 < ulrik> You have made a lot of good work with the particles I can see
22:20  * pxegeek waves hi - busy with work stuff
22:20 < ulrik> i'm fine thanks
22:20 < genete> ulrik: yes and still making modifications... :)
22:21 < ulrik> nice, you're hooked on synfig
22:21 < ulrik> :) 
22:21 < genete> :)
22:21 < ulrik> I have given up the latest mac os and returned to "tiger", so now synfig works as it should
22:22 < genete> there are some news of synfig about MacOs. Have you followed the logs? htodd have packaged for fork I think 
22:22 < ulrik> except for one problem with ffmpeg
22:22 < ulrik> for fink, yes
22:22 < genete> yes fink, 
22:23 < ulrik> is it ready?, the latest days there is no log
22:23 < ulrik> no log at dooglus place either
22:23 < pxegeek> yes, it's posted on the fink repository
22:23 < genete> for the latests news I think he had packaged core and studio
22:23 < ulrik> ok, maybe i should give it a try then
22:24 < ulrik> I have to do it later though, right now i'm building the latest r from svn with macports
22:25 < ulrik> but synfig-core fails when ffmpeg is installed
22:25 < ulrik> if I uninstall ffmpeg synfig-core builds ok
22:26 < genete> I know that there are some workarounds for ffmpeg for windows but I don't know if they are valid for mac. I think it is in the wiki 
22:26 < ulrik> i get this messages: /opt/local/include/ffmpeg/avcodec.h:2288: warning: 'ImgReSampleContext' is deprecated (declared at /opt/local/include/ffmpeg/avcodec.h:2282)
22:26 < ulrik> trgt_av.cpp: In member function 'bool VideoEncoder::write_frame(AVFormatContext*, AVStream*, AVFrame*)':
22:26 < ulrik> trgt_av.cpp:392: warning: 'img_convert' is deprecated (declared at /opt/local/include/ffmpeg/avcodec.h:2450)
22:26 < ulrik> trgt_av.cpp:394: warning: 'img_convert' is deprecated (declared at /opt/local/include/ffmpeg/avcodec.h:2450)
22:26 < ulrik> trgt_av.cpp: In member function 'void Target_LibAVCodec::LibAVEncoder::CleanUp()':
22:26 < ulrik> trgt_av.cpp:677: error: cannot convert 'ByteIOContext**' to 'ByteIOContext*' for argument '1' to 'int url_fclose(ByteIOContext*)'
22:26 < ulrik> make[4]: *** [libmod_libavcodec_la-trgt_av.lo] Error 1
22:26 < ulrik> make[3]: *** [all-recursive] Error 1
22:26 < ulrik> make[2]: *** [all-recursive] Error 1
22:26 < ulrik> make[1]: *** [all-recursive] Error 1
22:26 < ulrik> make: *** [all] Error 2
22:26 < ulrik> I have no idea what it means
22:27 < genete> me either...
22:27 < ulrik> genete: aha, I'll check the wiki to see
22:27 < ulrik> it's strange because it worked with ffmpeg before :( 
22:34 < dooglus> ooh activity in #synfig - I just noticed.
22:34 < dooglus> hi guys
22:34 < genete> hi dooglus 
22:35 < ulrik> hi dooglus
22:45 < dooglus> ulrik: do you not see logs here?  http://dooglus.rincevent.net/synfig/logs/2008/?C=M;O=D
22:52  * dooglus just made a tiny bit of progress :)
23:41 -!- MangoFusion [n=jamesu@host81-132-118-101.range81-132.btcentralplus.com] has quit []
23:51 -!- MangoFusion [n=jamesu@host81-132-118-101.range81-132.btcentralplus.com] has joined #synfig
--- Log closed Mon Jan 21 00:00:30 2008