Re: [PyOpenGL-Users] Pyopengl - slow performance using

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

On 1/14/2011 12:22 PM, Pedro Miranda wrote:
> But is someone sure that the proposed strategy to use
> NaN to separate different road segments is viable?

Actually, no, sorry -- now that I think about it more, I think we found 
that NaNs behaved differently on different Video Cards, so that may not 
be safe.

> [[(-45005.21, 168113.25), (-45003.77, 168112.71), (-44995.30,
> 168109.057)]]
>
> How can I convert this lineVert to a numpy array and create a "big"
> array containing all lineVerts?

numpy arrays are fixed size, so your best bet is to create a big list 
first, and the convert to numpy arrays. Something like:

for i in xrange(num_segments):
     lineVert.extend(self.shp.read_object(i).vertices())

line_array = np.array(lineVert, dtype=np.float32)

That will put them all sequentially together. In real use, you will want 
to either:
   create one numpy array for each connected set of segments -- you can 
do that by seeing if the endpoint of one is the startpoint of the next

or

   Keep track of the indexes where the breaks occur, and I think you can 
then  put it all in a VBO or VertexArray, and index into that to draw 
each contiguous line. Sorry, I didn't write the OpenGL part of MapRoom, 
so I have only a hazy idea of how this works.

> Is there any upper limit to maximum number of vertices a vertex array
> can contain?

probably only memory limits.

> d) VBO ------ The next step in the development of the application
> (after the map layer is smoothly drawn in openGL) is to draw a series
> of routes on top of the map (static). However, in this case this data
> can be more dynamic because the user can select the time interval of
> the data that is shown. I will definitely consider in that case using
> VBO.

Though I suspect that the route data is MUCH less, so performance may 
not be an issue -- VBOS may be a good way to do  anyway.

\> e) number of vertices per objMap (vertex array)
> ----------------------------------------------- I was checking and
> there are : - 7 vertices in average per vertex array - 2 vertices is
> the minimum number of vertices per vertex array - 272 vertices is the
> maximum mumber of vertices per vertex array
>
> So the average is pretty low and making so many calls to openGL
> routines is certainly good.

yes -- that is you key problem, you need to join the ones together that 
are contiguous, at least. I'd test that and see what the numbers look like.

> f) maproom ----------
>
> Thank you for sending the link of maproom. I will install it and
> check how it works. The API contains lots of useful functionality!
> Collaboration seems a good idea; let's see how thinks evolve.

OK -- it's been sleeping a bit after Dan Helfman left us -- but we are 
picking it up again, and probably hiring a new developer to work on it 
-- anyone looking for work in Seattle?

I'll try to see if I can add loading of shape files like yours to it 
next week -- we do want that eventually.

> FYI: I have recently found that Quantum GIS has python bindings as
> well. You can find more information in
> http://www.qgis.org/pyqgis-cookbook/

Yup -- QGIS is really nice, and can be used as a toolkit for building 
custom apps -- we're not using it because we have data that does not fit 
into the standard GIS data model, and we want to be able to draw fast 
and interactrively edit big data sets -- QGIS doesn't (or didn't when we 
evaluated it) do that very well.

Perhaps it's a good option for you, though.

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