Re: Help with VAOs

Yes, glumpy is kind of personal laboratory for experiencing new rendering techniques. In the end (next March), everything that is in glumpy should be available in vispy as well.

Nicolas

> On 27 Jan 2015, at 23:44, Chris Barker <[email protected]> wrote:
> 
> Nicolas,
> 
> It looks from docs like VisPY is kind of a next-generation Glumpy -- but is there still stuff in Glumpy that isn't in VisPy?
> 
> -Chris
> 
> 
> On Tue, Jan 27, 2015 at 2:33 PM, Nicolas P. Rougier <[email protected]> wrote:
> 
> Maybe this tutorial can help you:
> 
> http://www.labri.fr/perso/nrougier/teaching/opengl/
> 
> 
> Along with these two projects:
> 
> * http://glumpy.github.io
> * http://vispy.org
> 
> 
> Nicolas
> 
> 
> > On 27 Jan 2015, at 22:39, Chris Barker <[email protected]> wrote:
> >
> > Sorry, I'm going to be really vague here, as it's been a while.
> >
> > glBegin()
> > glVertex(...)
> > [...]
> > glEnd()
> >
> > is the "old" way, and you are right, you really  don't want to do that.
> >
> > The "new" way is all the shader magic - it may be time to bite the bullet and learn that.
> >
> > But the semi-new way is to use Vertex Buffer OBjects (VBOs) to efficiently store your vertices on the Card. A little googling should get you started.
> >
> > -CHB
> >
> >
> >
> > On Tue, Jan 27, 2015 at 12:36 PM, Johannes Bauer <[email protected]> wrote:
> > Hello list,
> >
> > I'm trying to store objects (currently only vertices) on the graphics
> > card so that I can avoid lots of:
> >
> > glBegin()
> > glVertex(...)
> > [...]
> > glEnd()
> >
> > I've tried lots and lots of code now (none of which fully did what I
> > wanted) and really am losing my mind soon :-( I could adapt this to work
> > with my code:
> >
> > https://gist.github.com/MorganBorman/4243336
> >
> > And it does work, but when integrated in my 3D environment I noticed
> > that the drawn objects are not rendered perspectively, but just a flat
> > object.
> >
> > I'm looking for the easiest way to dump a bunch of vertices onto the
> > graphics card and later reference those vertices to draw some object and
> > have it render as if I had used glBegin(), glVertex(), glEnd(). Is this
> > possible at all? Which approach should I look into?
> >
> > In general I've seen two different approaches, one that involes (usually
> > super-primitive) shaders, others do not. I do not see why I would need a
> > custom-shader for this task, is this really necessary?
> >
> > My goal ultimately is to store surfaces (i.e. vertices, their normals,
> > their texture UV coordinates) on the graphics card.
> >
> > Any help is greatly appreciated,
> > Johannes
> >
> > ------------------------------------------------------------------------------
> > Dive into the World of Parallel Programming. The Go Parallel Website,
> > sponsored by Intel and developed in partnership with Slashdot Media, is your
> > hub for all things parallel software development, from weekly thought
> > leadership blogs to news, videos, case studies, tutorials and more. Take a
> > look and join the conversation now. http://goparallel.sourceforge.net/
> > _______________________________________________
> > PyOpenGL Homepage
> > http://pyopengl.sourceforge.net
> > _______________________________________________
> > PyOpenGL-Users mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/pyopengl-users
> >
> >
> >
> > --
> >
> > Christopher Barker, Ph.D.
> > Oceanographer
> >
> > Emergency Response Division
> > NOAA/NOS/OR&R            (206) 526-6959   voice
> > 7600 Sand Point Way NE   (206) 526-6329   fax
> > Seattle, WA  98115       (206) 526-6317   main reception
> >
> > [email protected]
> > ------------------------------------------------------------------------------
> > Dive into the World of Parallel Programming. The Go Parallel Website,
> > sponsored by Intel and developed in partnership with Slashdot Media, is your
> > hub for all things parallel software development, from weekly thought
> > leadership blogs to news, videos, case studies, tutorials and more. Take a
> > look and join the conversation now. http://goparallel.sourceforge.net/_______________________________________________
> > PyOpenGL Homepage
> > http://pyopengl.sourceforge.net
> > _______________________________________________
> > PyOpenGL-Users mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/pyopengl-users
> 
> 
> 
> 
> -- 
> 
> Christopher Barker, Ph.D.
> Oceanographer
> 
> Emergency Response Division
> NOAA/NOS/OR&R            (206) 526-6959   voice
> 7600 Sand Point Way NE   (206) 526-6329   fax
> Seattle, WA  98115       (206) 526-6317   main reception
> 
> [email protected]


------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
PyOpenGL Homepage
http://pyopengl.sourceforge.net