[Gridflow-dev] [PD] [gemdead]
Antonio Roberts
antonio at hellocatfood.com
Sat May 7 09:17:24 EDT 2011
I've just come across [pix-preview], which is part of the pdvjtools
package http://hangar.org/wikis/lab/lib/exe/detail.php?id=start%3Apuredata_pdvjtools&media=start:pix_preview_help_patch.png
Looks like it does similar to [gem_see] object that was just created...
On 30 April 2011 20:06, Antonio Roberts <antonio at hellocatfood.com> wrote:
> This is amazing, thanks to you both!
>
> Ant
>
> On 30 April 2011 18:05, Jack <jack at rybn.org> wrote:
>> Something like this could help.
>> ++
>>
>> Jack
>>
>>
>>
>> Le samedi 30 avril 2011 à 12:06 +0100, ALAN BROOKER a écrit :
>>> Hey Ant,
>>>
>>> This can definitely be done- I was working on/off on a sort of ' #see
>>> for gem' but haven't perfected it yet.
>>>
>>> The method is to render 3d objects into a buffer > to pix object >
>>> then to #from_pix. Mathieu may know of a more efficient way of doing
>>> this tho
>>>
>>> The attached patch (if it doesn't work when first opened, close then
>>> re-open and should work) is what I was working on. As mentioned it's a
>>> work in progress and I could probably do with some efficiency tips
>>> here too!
>>>
>>> All the best
>>>
>>> Al
>>>
>>>
>>>
>>>
>>> On Sat, Apr 30, 2011 at 10:19 AM, Antonio Roberts
>>> <antonio at hellocatfood.com> wrote:
>>> > Thanks and sorry that I didn't stick around to get the reply on IRC.
>>> >
>>> > Secondly, can the cube be rendered to an [#out window] object? I know
>>> > [#from_pix] can handle [pix_] objects, and I've tried using a [cube]
>>> > as a [pix_texture] that I can then send to [#from_pix] but no luck so
>>> > far
>>> >
>>> > Ant
>>> >
>>> > On 30 April 2011 01:04, Mathieu Bouchard <matju at artengine.ca> wrote:
>>> >>
>>> >> from irc #dataflow :
>>> >>
>>> >> <hellocatfood> Is it possible to use [gemdead] with objects such as [cube]
>>> >> and [sphere] in gridflow?
>>> >>
>>> >> In theory, I said no, but actually, [gemdead] doesn't prevent you from using
>>> >> OpenGL elements, and things like [cube] and [sphere] don't check at all
>>> >> whether they're given a real [gemhead] context, and don't seem to be doing
>>> >> much that is related to it, therefore :
>>> >>
>>> >> [gemhead]
>>> >> |
>>> >> [b]
>>> >> |
>>> >> [gemdead]
>>> >> |
>>> >> [cube]
>>> >>
>>> >> will really draw the cube as if you had done :
>>> >>
>>> >> [gemhead]
>>> >> |
>>> >> [cube]
>>> >>
>>> >> I suspect that very few Gem object classes really depend on an authentic
>>> >> GemState (one that was really created by [gemwin]). When you do find
>>> >> exceptions, please tell me.
>>> >>
>>> >> But you may have to use [gemhead] anyway (as in the above example) as long
>>> >> as [gemwin] decides when to clear the buffer and when to copy the buffer to
>>> >> the screen, just because [gemwin] uses [gemdead] to say when it's the time
>>> >> to draw.
>>> >>
>>> >> _______________________________________________________________________
>>> >> | Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
>>> >>
>>> >
>>> > _______________________________________________
>>> > Pd-list at iem.at mailing list
>>> > UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>>> >
>>> _______________________________________________
>>> Gridflow-dev mailing list
>>> Gridflow-dev at lists.artengine.ca
>>> http://lists.artengine.ca/cgi-bin/mailman/listinfo/gridflow-dev
>>
>>
>
More information about the Gridflow-dev
mailing list