Wetterberg

I have a bit of a problem with my patch. I can't say it's the first time 

I've seen it, but here it's very very prominent.

Please have a look at this image, where the problem is very visible:

http://flickr.com/photos/andreaswetterberg/1257695790/

The above is an image done with "erase_color 0. 0. 0. 0." inside a 

It appears that about every 11th or 23th rendered circle is rendered 

twice, on top of itself, resulting in this weird sequence of 

I'm using a "qmetro 5" to handle the rendering timing, and I'd like to 

know if there is anything that can be done to eliminate or at least 

reduce the amount of errors in there. If you really really really need 

to I can try boiling the patch down a bit, but it's pretty complicated, 

so I am hoping we can make due without that..

Is what we are seeing here the aforementioned "bad jitter" ?

Hi friends,
I have a bit of a problem with my patch. I can't say it's the first time 
I've seen it, but here it's very very prominent.

Please have a look at this image, where the problem is very visible:
http://flickr.com/photos/andreaswetterberg/1257695790/

The above is an image done with "erase_color 0. 0. 0. 0." inside a 
particle system I have built.
It appears that about every 11th or 23th rendered circle is rendered 
twice, on top of itself, resulting in this weird sequence of 
transparent->opaque.

I'm using a "qmetro 5" to handle the rendering timing, and I'd like to 
know if there is anything that can be done to eliminate or at least 
reduce the amount of errors in there. If you really really really need 
to I can try boiling the patch down a bit, but it's pretty complicated, 
so I am hoping we can make due without that..

Is what we are seeing here the aforementioned "bad jitter" ?
Cheers,
Andreas.


rendering-problem

> Please have a look at this image, where the problem is very visible:

> The above is an image done with "erase_color 0. 0. 0. 0." inside a

> It appears that about every 11th or 23th rendered circle is rendered

> twice, on top of itself, resulting in this weird sequence of

Hi Andreas, considering the 2 particles appear in exactly the same place,

whereas the others are evenly spaced, there are 2 things that I can think

- round off error. Are you using integer values to calculate the position of

- related to the timing jittering. I don't know that you use to generate the

particles, but if you can implement some kind of exact time-stamping

mechanism, you'll be able to determine if you already rendered at that exact

position, so you can skip the 2nd/ double rendering.

If the problem is related to your metro, changing the performance settings

in Jitter will affect the amount / pattern of the double particles. If not I

On 8/28/07, Andreas Wetterberg  wrote:
>
>
> Please have a look at this image, where the problem is very visible:
> http://flickr.com/photos/andreaswetterberg/1257695790/
>
> The above is an image done with "erase_color 0. 0. 0. 0." inside a
> particle system I have built.
> It appears that about every 11th or 23th rendered circle is rendered
> twice, on top of itself, resulting in this weird sequence of
> transparent->opaque.

Hi Andreas, considering the 2 particles appear in exactly the same place,
whereas the others are evenly spaced, there are 2 things that I can think
of:

- round off error. Are you using integer values to calculate the position of
the particles maybe?

- related to the timing jittering. I don't know that you use to generate the
particles, but if you can implement some kind of exact time-stamping
mechanism, you'll be able to determine if you already rendered at that exact
position, so you can skip the 2nd/ double rendering.

If the problem is related to your metro, changing the performance settings
in Jitter will affect the amount / pattern of the double particles. If not I
suspect it might be a round off thing.

On Aug 28, 2007, at 4:41 AM, Andreas Wetterberg wrote:

> I'm using a "qmetro 5" to handle the rendering timing, and I'd like 

> to know if there is anything that can be done to eliminate or at 

> least reduce the amount of errors in there. If you really really 

> really need to I can try boiling the patch down a bit, but it's 

> pretty complicated, so I am hoping we can make due without that..

Just speculating in the absence of an example patch, but it sounds 

like you might be driving your rendering with one qmetro and the 

movement of the circle with a different qmetro or other time source 

like line. This is not recommended for this sort of thing where you 

need every frame to be unique. In such a case, you'll need to use the 

same source to a render frame *and* increment your animation. If you 

don't, you risk multiple renders of the same frame, which as best as 

I can tell is what's happening in your example. The bline and counter 

If this is not the case, and you are in fact using a single source to 

render a frame and increment your animation, then I suppose there's 

something off in your programming, and you'd need to post a patch 

> I'm using a "qmetro 5" to handle the rendering timing, and I'd like  
> to know if there is anything that can be done to eliminate or at  
> least reduce the amount of errors in there. If you really really  
> really need to I can try boiling the patch down a bit, but it's  
> pretty complicated, so I am hoping we can make due without that..

Just speculating in the absence of an example patch, but it sounds  
like you might be driving your rendering with one qmetro and the  
movement of the circle with a different qmetro or other time source  
like line. This is not recommended for this sort of thing where you  
need every frame to be unique. In such a case, you'll need to use the  
same source to a render frame *and* increment your animation. If you  
don't, you risk multiple renders of the same frame, which as best as  
I can tell is what's happening in your example. The bline and counter  
objects are useful for such tasks.

If this is not the case, and you are in fact using a single source to  
render a frame and increment your animation, then I suppose there's  
something off in your programming, and you'd need to post a patch  
(*always* encouraged).

> On Aug 28, 2007, at 4:41 AM, Andreas Wetterberg wrote:

>> I'm using a "qmetro 5" to handle the rendering timing, and I'd like 

>> to know if there is anything that can be done to eliminate or at 

>> least reduce the amount of errors in there. If you really really 

>> really need to I can try boiling the patch down a bit, but it's 

>> pretty complicated, so I am hoping we can make due without that..

> Just speculating in the absence of an example patch, but it sounds 

> like you might be driving your rendering with one qmetro and the 

> movement of the circle with a different qmetro or other time source 

> like line. This is not recommended for this sort of thing where you 

> need every frame to be unique. In such a case, you'll need to use the 

> same source to a render frame *and* increment your animation. If you 

> don't, you risk multiple renders of the same frame, which as best as I 

> can tell is what's happening in your example. The bline and counter 

Hi Joshua. The patch itself is an extensive mod of the jit.p.bounds 

helpfile, but with a separate, line-based rotation controller. However, 

the problem occurs even without rotating the jit.gl.gridshape object I 

I ended up building a smaller patch just to test this doubling effect, 

but I came up with nothing conclusive. It appears to be related so 

simply drawing trails with erase_color, but I can't put my finger on it.

Joshua Kit Clayton skrev:
>
> On Aug 28, 2007, at 4:41 AM, Andreas Wetterberg wrote:
>
>> I'm using a "qmetro 5" to handle the rendering timing, and I'd like 
>> to know if there is anything that can be done to eliminate or at 
>> least reduce the amount of errors in there. If you really really 
>> really need to I can try boiling the patch down a bit, but it's 
>> pretty complicated, so I am hoping we can make due without that..
>
>
> Just speculating in the absence of an example patch, but it sounds 
> like you might be driving your rendering with one qmetro and the 
> movement of the circle with a different qmetro or other time source 
> like line. This is not recommended for this sort of thing where you 
> need every frame to be unique. In such a case, you'll need to use the 
> same source to a render frame *and* increment your animation. If you 
> don't, you risk multiple renders of the same frame, which as best as I 
> can tell is what's happening in your example. The bline and counter 
> objects are useful for such tasks.
Hi Joshua. The patch itself is an extensive mod of the jit.p.bounds 
helpfile, but with a separate, line-based rotation controller. However, 
the problem occurs even without rotating the jit.gl.gridshape object I 
have on the end.

I ended up building a smaller patch just to test this doubling effect, 
but I came up with nothing conclusive. It appears to be related so 
simply drawing trails with erase_color, but I can't put my finger on it.

Just to revisit this thread for a little while: I took the time today to 

replace all lines with blines, as well as diving deep into the patch and 

changing a [t b erase] to a [t b "my stuff" erase] and that appears to 

now all metros are replaced with counters and [sel 0] fed from that "my 

stuff" point. Works really well. Thank you for your help.

Joshua Kit Clayton skrev:
>
> On Aug 28, 2007, at 4:41 AM, Andreas Wetterberg wrote:
>
>> I'm using a "qmetro 5" to handle the rendering timing, and I'd like 
>> to know if there is anything that can be done to eliminate or at 
>> least reduce the amount of errors in there. If you really really 
>> really need to I can try boiling the patch down a bit, but it's 
>> pretty complicated, so I am hoping we can make due without that..
>
>
> Just speculating in the absence of an example patch, but it sounds 
> like you might be driving your rendering with one qmetro and the 
> movement of the circle with a different qmetro or other time source 
> like line. This is not recommended for this sort of thing where you 
> need every frame to be unique. In such a case, you'll need to use the 
> same source to a render frame *and* increment your animation. If you 
> don't, you risk multiple renders of the same frame, which as best as I 
> can tell is what's happening in your example. The bline and counter 
> objects are useful for such tasks.
Just to revisit this thread for a little while: I took the time today to 
replace all lines with blines, as well as diving deep into the patch and 
changing a [t b erase] to a [t b "my stuff" erase] and that appears to 
have helped enormously.
now all metros are replaced with counters and [sel 0] fed from that "my 
stuff" point. Works really well. Thank you for your help.

rendering problem