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
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@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
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@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@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@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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@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@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@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Gridflow-dev mailing list Gridflow-dev@lists.artengine.ca http://lists.artengine.ca/cgi-bin/mailman/listinfo/gridflow-dev
This is amazing, thanks to you both!
Ant
On 30 April 2011 18:05, Jack jack@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@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@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@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Gridflow-dev mailing list Gridflow-dev@lists.artengine.ca http://lists.artengine.ca/cgi-bin/mailman/listinfo/gridflow-dev
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...
Looks like it does similar to [gem_see] object that was just created...
On 30 April 2011 20:06, Antonio Roberts antonio@hellocatfood.com wrote:
This is amazing, thanks to you both!
Ant
On 30 April 2011 18:05, Jack jack@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@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@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@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Gridflow-dev mailing list Gridflow-dev@lists.artengine.ca http://lists.artengine.ca/cgi-bin/mailman/listinfo/gridflow-dev
Hey Jack cheers! that's what I needed :)
Love the [#see] object, beyond it's practical use I just like having visual output on the same space as the patch Think I checked out pdvjtools before but could get it to compile-while try again
On Sat, May 7, 2011 at 2:17 PM, Antonio Roberts antonio@hellocatfood.com wrote:
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...
Looks like it does similar to [gem_see] object that was just created...
On 30 April 2011 20:06, Antonio Roberts antonio@hellocatfood.com wrote:
This is amazing, thanks to you both!
Ant
On 30 April 2011 18:05, Jack jack@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@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@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@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Gridflow-dev mailing list Gridflow-dev@lists.artengine.ca http://lists.artengine.ca/cgi-bin/mailman/listinfo/gridflow-dev
hi,
just discovering and learning GF. thanks for amazing piece of software!
but something is not doing what i expect it should or would do...
[tgl] | [metro 40] | [pdp_noise] | [#from_pdp] | [#see]
displays only first frame it gets and then i cannot persuade it to show any other. am i missing something?
pdextended 42.5 gridflow 9.12
best, luka
On Sun, 1 May 2011, Luka Prinčič // Nova deViator wrote:
[pdp_noise] | [#from_pdp] | [#see]
displays only first frame it gets and then i cannot persuade it to show any other. am i missing something?
Mr. Buzz reported the same problem, with a [pdp_plasma] example, 7 weeks ago, but I haven't found the problem back then, and I haven't looked since.
If anyone with experience with the PDP source wants to look at gridflow/src/pdp.cxx, welcome... That, and [#to_pdp], were my first PDP externals ever.
http://gridflow.ca/svn/trunk/src/pdp.cxx
The [#from_pdp] section is only 52 lines long, if that happens to reassure anyone.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
-
ALAN BROOKER -
Antonio Roberts -
Jack -
Luka Prinčič // Nova deViator -
Mathieu Bouchard