pyopengl-users

[PyOpenGL-Users] Help with VAOs

[Johannes B. <dfn...@gm...>]

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

Re: [PyOpenGL-Users] Help with VAOs

[Chris B. <chr...@no...>]

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 <dfn...@gm...>
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
> PyO...@li...
> 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

Chr...@no...

Re: [PyOpenGL-Users] Help with VAOs

[Nicolas P. R. <Nic...@in...>]

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 <chr...@no...> 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 <dfn...@gm...> 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
> PyO...@li...
> 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
> 
> Chr...@no...
> ------------------------------------------------------------------------------
> 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
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users

Re: [PyOpenGL-Users] Help with VAOs

[Chris B. <chr...@no...>]

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 <
Nic...@in...> 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 <chr...@no...> 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 <dfn...@gm...>
> 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
> > PyO...@li...
> > 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
> >
> > Chr...@no...
> >
> ------------------------------------------------------------------------------
> > 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
> > PyO...@li...
> > 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

Chr...@no...

Re: [PyOpenGL-Users] Help with VAOs

[Nicolas P. R. <Nic...@in...>]

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 <chr...@no...> 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 <Nic...@in...> 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 <chr...@no...> 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 <dfn...@gm...> 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
> > PyO...@li...
> > 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
> >
> > Chr...@no...
> > ------------------------------------------------------------------------------
> > 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
> > PyO...@li...
> > 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
> 
> Chr...@no...

Re: [PyOpenGL-Users] Help with VAOs

[Chris B. <chr...@no...>]

On Tue, Jan 27, 2015 at 9:26 PM, Nicolas P. Rougier <
Nic...@in...> wrote:

>
> Yes, glumpy is kind of personal laboratory for experiencing new rendering
> techniques. In the end (next March),


as in a couple months? or more than a year?

But it looks like Glumpy is a good place to look for sample code, in any
case.

Thanks,
   -Chris



-- 

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

Chr...@no...

Re: [PyOpenGL-Users] Help with VAOs

[Mads I. <mad...@gm...>]

This tutorial/sample initially got me going:

http://www.lighthouse3d.com/cg-topics/code-samples/opengl-3-3-glsl-1-5-sample/

On 27/01/15 21:36, Johannes Bauer 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
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>

-- 
+---------------------------------------------------------------------+
| Mads Ipsen                                                          |
+----------------------------------+----------------------------------+
| Overgaden Oven Vandet 106, 4.tv  | phone:              +45-29716388 |
| DK-1415 København K              | email:      mad...@gm... |
| Denmark                          | map  : https://goo.gl/maps/oQ6y6 |
+----------------------------------+----------------------------------+

Re: [PyOpenGL-Users] Help with VAOs

[rndblnch <rnd...@gm...>]

Johannes Bauer <dfnsonfsduifb <at> gmx.de> writes:

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

you may find this tutorial useful:
https://bitbucket.org/rndblnch/opengl-programmable/src

it shows the transformation of a minimal sample from direct mode to the
"modern" programmable pipeline step by step.
you can easily diff two successive versions of the code, e.g.:

diff 01-direct.py 03-array.py 
5c5
< 01-direct.py
---
> 03-array.py
7c7
< OpenGL 1.0 rendering using per vertex primitive
---
> OpenGL 1.1 rendering using arrays
71a72,75
> def flatten(*lll):
> 	return [u for ll in lll for l in ll for u in l]
> 
> 
72a77,83
> 	# enabling arrays
> 	glEnableClientState(GL_VERTEX_ARRAY)
> 	glEnableClientState(GL_TEXTURE_COORD_ARRAY)
> 	glEnableClientState(GL_NORMAL_ARRAY)
> 	glEnableClientState(GL_COLOR_ARRAY)
> 	
> 	# model data
76,79c87,90
< 	verticies, tex_coords, normals, colors = (model.verticies,
< 	                                          model.tex_coords,
< 	                                          model.normals,
< 	                                          model.colors)
---
> 	verticies  = flatten(model.verticies)
> 	tex_coords = flatten(model.tex_coords)
> 	normals    = flatten(model.normals)
> 	colors     = flatten(model.colors)
82a94,98
> 	glVertexPointer(3, GL_FLOAT, 0, verticies)
> 	glTexCoordPointer(3, GL_FLOAT, 0, tex_coords)
> 	glNormalPointer(GL_FLOAT, 0, normals)
> 	glColorPointer(3, GL_FLOAT, 0, colors)
> 	
90,97c106,108
< 		glBegin(GL_TRIANGLE_STRIP)
< 		for i in range(offset, offset+size):
< 			index = indicies[i]
< 			glColor3f(*colors[index])
< 			glNormal3f(*normals[index])
< 			glTexCoord3f(*tex_coords[index])
< 			glVertex3f(*verticies[index])
< 		glEnd()
---
> 		glDrawElements(GL_TRIANGLE_STRIP,
> 		               size, GL_UNSIGNED_INT,
> 		               indicies[offset:offset+size])

renaud