[PD-dev] Gem CVS Bug (wrong alarm ??)

Daniel Heckenberg daniel at bogusfront.org
Sat Nov 16 07:50:17 CET 2002


On the texture versus texture2 question: what's the precedent for this sort
of thing in PD/GEM?  Should a single object have multiple modes that support
different messages, or should the different modes appear as different
objects?

GL_TEXTURE_RECTANGLE_??:
The issue of extensions on Windows is a bit cumbersome because support is
entirely dependent on the driver you're using... so you have do to run-time
checks and run-time function bindings for the desired extensions.

High level/low level
I think what is really desirable is to have low-level and high level
functionality together... somewhat like GL and GLU.   I don't think you can
do without the low-level if you want flexibility, but straightforward
support for things like parameterized models would be great...

The biggest issues I've found with GEM are in data management and render
flow control which both get quite awkward...  these are partly problems that
also occur in PD... generalized matrix formulations of things would be
really good.  (hello, Gridflow!)

Is a GEM redesign in the works?  I'd be interested to hear more about this
and contribute what I can...

daniel


> If possible I am for a single texture object, from a users point of
> view.
> I have been discussing a lot with Johannes the topic of going
> to lower levels ( as DIPS does for example).
>
> We have to take care to balance the usability/flexibility tradeoff.
> It is true that one single texture reduces flexibility to a certain
> amount.
>
> I think to regain this we could have another, low level access to
> OpenGL functionality, for "power users".
>
> Specifically, in order to get Gem out of the "hacker domain"
> we have to think a lot about usability and general concept.
>
> Regarding Erichs problem, I think we should add and alias
> texture2->texture. I did this on the "old" CVS (soon to disappear).
>
>
> Greetings,
>
> Guenter
>
>
>
> On Thu, 14 Nov 2002, chris clepper wrote:
>
> > >I think that it's a good idea to keep separate pix_texture and
> pix_texture2
> > >objects because power of 2 textures work differently from
> non-pow2 textures,
> > >no matter what tricks/extensions you use to allow the use of non-pow2
> > >textures.   These differences are in the support for wrap
> modes, borders
> > >etc.
> > >
> > >Presently, a non-pow2 texture using texture coord scaling (as
> implemented by
> > >pix_texture2) will repeat but will include the black padding
> zones.  Using
> > >GL_TEXTURE_RECTANGLE_NV repeat is not supported at all.
> >
> > no if you give the coords in 0..height 0..width it will cover the
> > surface completely.
> >
> > >These behavioural differences can't be properly hidden, can they?  And
> > >sooner or later it would be nice to expose the wrap mode and
> border settings
> > >for control via messages to the pix_textureX object...
> >
> > yes.  the option for the user to do wrap or clamp_to_edge would be nice.
> >
> > >Details for nVidia's non-pow2 extension.
> >
> >http://www.nvidia.com/dev_content/nvopenglspecs/GL_NV_texture_rec
> tangle.txt
> >
> > thanks for the info.  this looks pretty close to the apple extension.
> >
> > >
> > >>  ...well, at least for the MacOSX build, we need both
> > >texture/texture2...this is because
> > >>  we use an extension for non-power of 2 textures that makes
> for incredibly
> > >fast
> > >>  performance...unfortunately, I don't know if the extension
> > >(GL_TEXTURE_RECTANGLE_EXT) is
> > >  > available on other platforms?
> > >
> > >Notwithstanding what I said above, the fast texture support on Mac OS X
> > >doesn't need to be used with non-pow2 textures, does it?
> >
> > no, but it sure cuts down on wasted bandwidth.  640*480 is a hell of
> > a lot fewer pixels than 1024*1024.  also IMHO the power of two
> > texture thing is just plain silly.  how many images do you run across
> > that conform to this?
> >
> > >The texture rectangle extension is available in the nvidia
> drivers... not
> > >sure about other vendors or MESA.
> >
> > it would be good to check the support for this under linux and windows.





More information about the Pd-dev mailing list