RE: Color lookup tables on multiple pipes.

New Message Reply Date view Thread view Subject view Author view

From: Mark Wear (mwear++at++paradigmsim.com)
Date: 03/15/2000 10:00:50


On a previous query, I got the response:
> "Each pipe should do this in a draw callback and it will just work. The
> pipes and contexts have separate state information, the draw processes
> and callbacks will operate on the current context on each pipe. "

The glColorTableSGI extension is not the same as the maps discussed in the
OpenGL Programming Guide, so I'm not sure the above statements are valid. As
I understand it, the color tables provided by the color table extension
allow you to adjust image contrast and brightness after each stage of the
pixel processing pipeline depending upon which target you specify. If you
specify GL_TEXTURE_COLOR_TABLE_SGI as the target, you have also selected
where in the pipeline the mapping will occur. Depending on where along the
pipeline this actually gets done, it may only be possible to implement a
single GL_TEXTURE_COLOR_TABLE_SGI mapping per system. ...Or, I could be
wrong.

A good test would be to load a model with Perfly on one pipe and start your
application on the other. If the textures within Perfly exhibit the problem,
then you have your answer. If not, you need to look further into your
contexts.

...Or, You could load the models with intensity textures and then not
disable the LUT at all, allowing the models to be colored by the LUT.

Good luck.

Mark Wear
Multigen-Paradigm Inc.
mwear++at++paradigmsim.com
http://www.multigen-paradigm.com
phone: 972-960-2301 fax: 972-960-2303

 -----Original Message-----
From: christopher.g.dorosky++at++lmco.com
[mailto:christopher.g.dorosky++at++lmco.com]
Sent: Wednesday, March 15, 2000 10:10 AM
To: info-performer++at++sgi.com
Subject: Color lookup tables on multiple pipes.

Sorry for the repeat post, but I am still having trouble.

In my scene, there is a terrain node which has all of the terrain data.
There are also various 3D models.
The source data for the terrain is greyscale. The source for the models is
color.
I can apply a color LUT to the terrain data, and get good results. I do not
want to apply the LUT to the models, because colorizing a color model has
bad results.

A solution, on a single pipe system, is to set up a color-LUT, and
selectively enable and disable it.

Since all terrain is under one node, applying a pre-draw and post-draw
callback that glEnables and glDisables GL_TEXTURE_COLOR_TABLE_SGI works
fine. The idea is that before terrain is drawn, the table is turned on, and
when terrain is done, the LUT is turned off. This works great on a one pipe
system.

On a two pipe system, I have not figured out how to make the system
understand the pipe context for the LUT's.

On a previous query, I got the response: "
> Each pipe should do this in a draw callback and it will just work. The
> pipes and contexts have separate state information, the draw processes
> and callbacks will operate on the current context on each pipe. "
>
However, what I see when running on two pipes, is intermittent color-to-grey
flashing of the terrain.
The pre and post draw callbacks appear to be running on both pipes.
If I place
if (!glIsEnabled(GL_TEXTURE_COLOR_TABLE_SGI)) { printf("table was already
off!!\n"); fflush(stdout); }
in the post draw callback, I get printouts at each flash (can happen several
times a second, but usually once every several seconds).

I have not successfully told the two pipes how to use or not use the LUT
without shutting it off for the other pipe.

Has anybody else run into this?

Christopher Dorosky
Senior Electronic Systems Engineer - Real Time Simulation
Lockheed Martin Missiles and Fire Control - Dallas
christopher.g.dorosky++at++lmco.com
972-603-2349
-----------------------------------------------------------------------
List Archives, FAQ, FTP: http://www.sgi.com/software/performer/
            Submissions: info-performer++at++sgi.com
        Admin. requests: info-performer-request++at++sgi.com


New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2b29 : Wed Mar 15 2000 - 10:01:11 PST

This message has been cleansed for anti-spam protection. Replace '++at++' in any mail addresses with the '@' symbol.