I need to do multitexturing, but I need to be able to also do it on hardware (or software) without multitexturing extensions.
What kind of implementations are there?
Be forewarned, I’m already at high polygon counts, and doubling them means killing app performance totally (from 5fps in software to sub-1fps).
– Question :
Is there any way to blend a second texture with a first texture WITHOUT the use of multitexturing? Is it possible or do I have to blend the two bitmaps together into one first?
Please - HELP!!! (I make this out to sound more urgent then it really is, cause I’m wierd like that! ).
Well … just draw the triangle with the first texture, then draw the same triangle with the other texture using whatever blendmode which is suitable.
By the way … i have a related problem, I can’t get multitexturing to work like I want. Do anyone know if glBlendFunc sets the same blending mode for both textures or just for the current when doing multitexturing?
Originally posted by Humus: Well … just draw the triangle with the first texture, then draw the same triangle with the other texture using whatever blendmode which is suitable.
Like I said, I can’t do that, as the polygon count doubles and becomes even more outrageous than it already is (I’m already pushing 100k+ polys), so I cannot have that happening.
But its a good thought. By the way, in case I didn’t make it clear in my first post, I need this to be functional with the Software implementations of OpenGL, therefore I cannot rely on ANY OpenGL extensions to be present for this operation.
Well … i guess that you can’t do anything to your problem. My advice is that you use the multitexturing extension if they are supported, otherwise you have to render each triangle two times. I guess there is no walk around for this kind of problems, you could preblend textures into each other but in most situations that will require massive amounts of video memory …
I don’t understand. If you need multitexturing, but then don’t have the extension, then you’ll just have to fall back to multipass. If you can live with per-vertex color blended with a texture, then you can use single texturing.
Well, between the 2 solutions, there is a third solution (no, the solution is not to get rid of multitexturing) : generate the textures by blending yourself the different textures, and then apply them in one pass. But he problem is that you will get a LOT of texture if you have a lot of combinations it will not be suitable…
So one thing I can tell you is to reduce the number of polygons if you can by some BSP algos or pre-clipping… It may speed your app
Originally posted by Siwko: Like I said, I can’t do that, as the polygon count doubles and becomes even more outrageous than it already is (I’m already pushing 100k+ polys), so I cannot have that happening.
2 passes needn’t be twice as slow. If you let OpenGL know that your vertices haven’t changed between the first and second passes, the cost of the second pass should be reduced somewhat.
One way to do this is to stick the geometry drawing commands into a display-list at startup and call it twice with a different texture bound each time.
Another way is to use compiled vertex-arrays (an extension).
If you’re drawing 100k polys per frame with MS software OpenGL, I don’t imagine you’d really notice your framerate halving through.
Originally posted by Mike F: One way to do this is to stick the geometry drawing commands into a display-list at startup and call it twice with a different texture bound each time.
Another way is to use compiled vertex-arrays (an extension).
I was thinking about that as well. I’m using vertex arrays to do all my geometry right now. However, I read that using display lists to store vertex array calls is very inefficient because of the memory organization that is involved. Is this true?
And second, I stress again, I cannot use glLockArrays because I have to ensure that the application is as widely system-compatible as possible, such that I cannot rely on OpenGL extensions at all (ie: it must be able to fall back to the software renderer if necessary).
Okay, let me detail myself - that might lead to more application specific solutions.
First, I’m only displaying one and only one model on the screen - a heightmap of sorts. This map can range from 1x1 to 4kx4k pixels, which gets converted into XYZ vertex data. From there, the XYZ coordinate data goes through a scaling pass which scales it (cleverly) to an index array, such that it can be rescaled dynamically. The only thing that ever changes is the index array.
Now, there are two texture maps. First is the color map that gets textured on the resulting image, and second, which is optional and thus currently multitextured because my hardware can handle it, is a contour line map. This second needs to be able to be turned on and off if the user request it. I’d prefer not to have to regenerate the textures every time I need to change the mode, because the contouring function is very expensive time-wise.
So, if that helps, and you have some idea, let me know. Multitexturing solves this problem perfectly for me, unfortunately, there’s no guarantee that the target platform will support it (like my boss’s laptop which has a crappy Trident video chip in it). So my reference target is the MS Software GL Driver.
Thanks in advance and post for all the suggestions made and those to come. HELP!!!
You should probably just make different paths within your own code. When multitexture is present, use it to do the contours – when it isn’t, either disallow them or fall back to two passes.
It is very difficult to use cool hardware features without getting hardware-specific to some degree. OpenGL exposes this through the ability to query at run-time, so that your app can choose which paths need to be used.
I’m not sure what you mean with contour line map. Maybe this can be rendered with lines and glPolygonOffset activated, so that the lines always display over the texture polygons. Can you provide a screenshot to get a better understanding?
Cass, exactly. Which is what I’m doing right now. But what I am looking for is a fast way to blend two textures into one without multipass or multitexture.
I’m fairly certain that I’m locked into creating two textures at runtime for systems without multitex ability right now. I just wanted to avoid this if there was any way for OpenGL to handle combining two textures without recreating a second set of geometry data.
Incedentally, the target platform is a 3Dlabs Oxygen card, which supports multitexture, so there’s no real impressing concern. However, like I said, this app is likely to be run by some non-target platforms which don’t have and hardware support. Its just a contingency I have to deal with.
).