[Bf-committers] Time offset questions

[Jeremy White]

Hey! I'm hoping to get used to blender and hopefully do the google SOC. 
If you've been on irc, you've no doubt already seen a lot of these 
questions when I'm logged in, and ton already warned me this would be 
hard, but I thought that a good gauge for if I can do the SOC is if I 
can crack a difficult bug. Now, that's not the questions at hand, so 
before I digress further:

I'm currently mucking around bug #6154 
http://projects.blender.org/tracker/?func=detail&atid=125&aid=6154&group_id=9
Read that page before you keep reading here. (grab a soda too, if you 
like. This is a long email)

So, here's my plan of attack and thoughts on what is wrong (please skip 
the first two paragraphs if you've been on irc with me, as this is just 
a rehash of my drama... minus the parts about punting kittens):

I see that drawview and drawobjects both are source files that have 
methods which seem to be tightly knit with the objects at hand and seem 
to handle the time offset correctly because they use less of the derived 
mesh and fewer assumptions seem to be made.

On the other hand, convertblender, which contains many of the methods 
I'd assume are where the rendering side of blender chooses what to draw 
and where to draw it, seems to make several more assumptions 
(particularly about dupli groups in this case) about the objects it 
draws to be more efficient and also relies more heavily on derived meshes.

My thoughts are that I need to find wherever it is that frame/time based 
transforms are applied to the objects that the renderer has decided to 
nab and draw and add a conditional (something like "if (ob->sf != 0.0) { 
/*then update the transforms differently*/}" or something else similar) 
which will hopefully just correct one of the oversights it seems there 
renderer is making.

I'm currently still looking for where the transforms occur, stirring up 
trouble on IRC (it's too easy), and generally adding to my already 
dangerously large list of assumptions above.

I really feel like almost no one knows how the offset stuff actually 
occurs. This is, of course, still doable I assume. The whole bug simply 
reeks of "oops! I forgot that one line of code there. Sorry!" And it's 
also boring for anyone who already knows the code for blender. So uh, 
let me know if I'm wrong anywhere on here. I probably stepped on several 
toes and ran a lot of red lights in all the stuff I presume, especially 
about the methods in convertblender.c

That is all...

Remember that only you can prevent brownie streaks,
~Dudy


P.S. Let me know if you want to know the crazy project ideas I'd like to 
try for this SOC. Most of them will give you an idea of how little of a 
life I have :-D