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.