rendering problem

Aug 28, 2007 at 11:41am

rendering problem

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:

max 2007-08-28 13-27-03-73

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.

#33441
Aug 28, 2007 at 2:05pm

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.

HTH, Thijs

http://www.nano-soundworks.com

#111435
Aug 28, 2007 at 2:39pm

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.

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).

-Joshua

#111436
Aug 29, 2007 at 12:12am

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.

Andreas.

#111437
Sep 7, 2007 at 10:13pm

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.

Andreas.

#111438

You must be logged in to reply to this topic.