HDTenEightyP/NetNews huggingface dataset:
From: pfk@rz.uni-jena.de (Frank Klemm)
Newsgroups: comp.graphics
Subject: Re: COLOR DITHERING REFERENCES?
Date: 14 Dec 92 20:18:42 GMT
Reply-To: pfk@rz.uni-jena.de (Frank Klemm)
Organization: Friedrich-Schiller-University Jena, Germany


In article <107270002@hpfcso.FC.HP.COM>, yip@hpfcso.FC.HP.COM (Tom Yip) writes:
|> Can anyone direct me to a reference for color dithering methods, and
|> dithering in general.  Books with sample C source would be ideal.
|> Please E-Mail me, as a may not see the response to this note.
|> 
Dithering of color is nearly the same as dithing of B/W. You must do it seperatly for
all 3 color planes. For DOS + SS24 I have programmed a sample using the 1280x1024x16, 1024x768x256,
800x600x32k and 640x480x16M color modes to display true color pictures (TARGA24).

Frank
Xref: sparky comp.graphics:13033 comp.graphics.visualization:1929 comp.graphics.animation:1367 comp.org.acm:1029
From: bvh@cse.unl.edu (Ben Hollingsworth)
Newsgroups: comp.graphics,comp.graphics.visualization,comp.graphics.animation,comp.org.acm
Subject: Re: Graphicon '93 Call for Participation
Date: 18 Dec 1992 05:53:38 GMT
Organization: University of Nebraska--Lincoln	
Distribution: world
NNTP-Posting-Host: cse.unl.edu

rsc@altair.csustan.edu (Steve Cunningham) writes:


!                      G R A P H I C O N '  93
!        The 3-rd Annual Conference for Computer Graphics and
!                      Visualization in Russia.

!     GRAPHICON'93 provides  an  opportunity to publish your own work
! and to know about works of your  colleagues  from  other  countries.
! Submitted   conference  papers  are  refereed  by  an  international
! programme  committee  and  accepted  papers  are  published  in  the
! Conference Proceedings which will be available at the Conference.

Any chance these Conference Proceedings will be available to the
general public?  These topics sound great, but the chances of a
college student making it to Russia in the middle of September are
pretty slim.

				-- Obi-Wan

--
 |\_/|  AACK! ||                        ||  "Obi-Wan" (Ben Hollingsworth)
\'o.0'/       ||  ... but at least      ||  MicroImages, Inc.  Lincoln, Nebraska
=(___)=       ||      we have quotas!   ||  University of Nebraska - Lincoln
   U   PTHAT! ||                        ||  email:  bvh@sioux.unl.edu
Newsgroups: comp.graphics
From: eghenry@ritchie.uwaterloo.ca (Ethan Gregory Henry)
Subject: Re: Graphics File Formats
Organization: University of Waterloo
Date: Thu, 17 Dec 1992 07:33:28 GMT

In article <1992Dec16.105933.1812@cnplss5.cnps.philips.nl>, schaik@cnplss5.cft.philips.nl (Willem van Schaik) writes:
> mccreary@sword.eng.hou.compaq.com (Ed McCreary) writes:
> 
> >In article <Bz3pv0.I01@news.cso.uiuc.edu> cl27111@uxa.cso.uiuc.edu (Christopher  Lindsey) writes:
> >>telliott@bbn.com (Thomas R Elliott) writes:
> >>
> >>>For those interest, I discovered a book by David C. Kay and John R. Levine
> >>>that describes many different graphics file formats.  The title is
> >>>"Graphics File Formats...
> >>>...The publisher is Windcrest/McGraw Hill and the price is $24.95.
> >>
> >>	Do you happen to know the ISBN number of this book?
> >>
> 
> >0-8306-3059-7
> 
> >None of the bookstores I called have it in stock.  In fact, only
> >one carried it.  The number to call to order it from the publisher
> >is 1-800-822-8138.  I'm considering getting it, but I don't like
> >to buy a book I haven't paged through.  Could someone who
> >has it or has read it post a *small* review?
> 
> I have the book and I like it. It provides basic data about a lot of 
> graphic formats without much distracting info like how to use it, etc.

Well, I got this book out of the library today by coincidence...

It seems to be a good, comprehensive book covering all the major graphic
file formats, giving enough technical detail to implement an interpreter
along with a bit of a pros/cons review for each format.

I would think that if you worked with bitmapped formats that this book 
would really be indespensible. Its coverage of vector formats is rather
limited, but it isn't a big problem - to use PostScript or CGM (ug) you
would want a copy of the full spec anyways.

And I've (tried) to work with CGM - horrible spec.

Ethan
Newsgroups: comp.graphics
From: orourke@sophia.smith.edu (Joseph O'Rourke)
Subject: Re: Calculating polygon areas
Organization: Smith College, Northampton, MA, US
Date: Wed, 16 Dec 1992 19:20:07 GMT

  In article <1992Dec16.173613.5737@medusa.prime.com> mrj@CIS.Prime.COM writes:
  >In article 24617@sophia.smith.edu, orourke@sophia.smith.edu (Joseph O'Rourke) writes:
    >> 	So if the coordinates of vertex v_i are x_i and y_i,
    >> 	twice the area of a polygon is given by
    >> 	2 \A( P ) = \sum_{i=0}^{n-1} (x_i y_{i+1} - y_i x_{i+1})
  >
  >There is a more general form of the above:
  >
  >	Area = 0.5 \sum_{i=0}^{n} (P_i X P_{i+1})         
  >
  >	s.t. i+1 = (i+1) mod n i.e. when i = n then P_{i+1} = P_0
  >Where X denotes a vector cross product. 

These are equivalent formulae: I just unraveled the cross product
into x and y coordinates.

  >The proof is simple. If anyone is interested I'll post it to the net.

I am interested to see a simple proof, yes.
From: rob@rjck.UUCP (Robert J.C. Kyanko)
Newsgroups: comp.graphics
Subject: Re: Looking for help on VESA programing.
Distribution: world
Date: Thu, 17 Dec 92 01:20:18 GMT
Organization: RJK Enterprises

djlewis@ualr.edu writes in article <1992Dec14.161316.1@ualr.edu>:

> > Just call this number (408) 435-0333, and they will send you a free package
> > with the whole specification and a disk.
> > Ask for the VESA Super VGA standard documentation
> > 
> > Hans van Oostrom                    KD4MUJ
> > PO Box J-254, JHMHC                 hans@ufpine                (BITNET)
> > Gainesville, FL  32601, USA         hans@pine.circa.ufl.edu    (INTERNET)
> >>>>          Hoe ver je ook gaat, overal zie je landgenoten           <<<
> 
> Hello all, 
> 	I have the above mentioned VESA kit. Be prepared to know PASCAL. I
> found a public domain pas to c convertor that helps but does'nt do it all. I
> asked for a "C" kit when I ordered it. The kit comes with old VESA drivers
> from some vendors (early91) and some early demo programs.
> 	I have a technical question. I have the STB Evolution VESA compliant
> card and am having a VERY difficult time getting the modes 0x101h, 0x103h,
> 0x104h, 0x105h or in other words, any 256colour mode. It appears to be a
> problem with VESA function 0x4F05 (SetVesaBank()). Anyone programming VESA
> modes want to share their experiance?

I recently did some VESA graphics programming and found it straight forward.
I didn't use the text mentioned.  I found it in a graphics book I have at
work (sorry, forgot title & author -- but it's a very popular & spoke about
book).  Just remember when you are switching banks, you need to work with
granules, not 64k banks.  Of course, simple division fixes this.  The granule
size can vary from implementation to implementation and is specified by
requesting mode information.  Also the bank size doesn't have to be 64k, but
I check to make sure.  All banks start at 0xA000:0.  Don't forget to subtract
the bank offset from your absolute screen address if you're not familiar with
bank switching; all writes must be contained within 0xa000:00000 - 0xa000:ffff.

--
I am not responsible for anything I do or say -- I'm just an opinion.
             Robert J.C. Kyanko (rob@rjck.UUCP)
From: d91-han@ludd.luth.se (Andersson Henrik)
Newsgroups: comp.graphics
Subject: FTParea for animations
Date: 15 Dec 92 14:31:34 GMT
Organization: Lule} Tekniska H|gskolas Datorf|rening - Ludd

Sorry I don't know if this question is in the FAQ.

... but I wounder if there exist any good ftp site (or other solution)
with animation files (like MPEG, .gl, .fli, .anim etc )

any response is presuated (even if its a small site)

d91-han@ludd.luth.se


                     /Hinken
Newsgroups: comp.graphics,comp.os.msdos.programmer
From: slindsay@nyx.cs.du.edu (Steve Lindsay)
Subject: Gprintf and setprecision
Organization: Nyx, Public Access Unix @ U. of Denver Math/CS dept.
Distribution: na
Date: Tue, 15 Dec 92 07:10:41 GMT


I have been trying to output floating point numbers to a DOS 
VGA screen graphics screen.  I am using Borland 3.1 C++and 
EGAVGA.BGI.  I found the below function in one of the example
 files.  It works great but there is a problem.  I want to only 
output 3 places right of the decimal point.  I have tried 
setprecision(2) right in front of my floating point variable 
on the gprintf line.  But it will not work.  I know why and
 that is because it is no longer a floating point but a string. 
Does anyone have an idea of how to out smart this little 
function and only let it output 3 places right of the decimal
point.
             .........Thanks!!...........

GPRINTF: Used like PRINTF except the output is sent to the*/
screen in graphics mode at the specified co-ordinate.  */

         
int gprintf( int *xloc, int *yloc, char *fmt, ... )
{
  va_list  argptr;              /* Argument list pointer */
  char str[140];              /* Buffer to build sting into  */
  int cnt;                     /* Result of SPRINTF for return /

  va_start( argptr, fmt );            /* Initialize va_ functions*/

  cnt = vsprintf( str, fmt, argptr );          /* prints string to buffer*/
  outtextxy( *xloc, *yloc, str);  /* Send string in graphics mode */
  *yloc += textheight( "H" ) + 2;       /* Advance to next line        */

  va_end( argptr );            /* Close va_functions         */

  return( cnt );                /* Return the conversion count*/

/ ************* BELOW is part of the include file *************

typedef void _FAR *va_list;

#define __size(x) ((sizeof(x)+sizeof(int)-1) & ~(sizeof(int)-1))

#if defined(__cplusplus) && !defined(__STDC__)
#define va_start(ap, parmN) (ap = ...)
#else
#define va_start(ap, parmN) ((void)((ap) = (va_list)((char _FAR 
*)(&parmN)+__size(parmN))))
#endif
From: kruzan@ohstpy.mps.ohio-state.edu
Newsgroups: comp.graphics
Subject: Radiosity?
Date: 20 Dec 92 21:15:13 EST
Organization: The Ohio State University, Department of Physics

I am looking for information on RADIOSITY.  Does anyone know location
of any source code on radiosity.  Also, anyone actually doing radiosity 
devlopment out there that I might ask questions?


Thanks.
From: bbrown@willamette.edu (Brian Brown)
Newsgroups: comp.graphics
Subject: VESA standard for SVGA needed
Date: 14 Dec 92 01:49:02 GMT
Article-I.D.: willamet.Bz87pq.nE
Organization: Willamette University, Salem OR


The subject line says it all -- I need to find a copy of the VESA standard
for SVGA boards (IBM-compat computers, of course).  Could someone please
point me in the right direction?

Thanks!

-- 
-----------------  bbrown@willamette.edu  (Brian W. Brown)  -----------------
Recently, a poll found that 75% of people approve of the way Bill Clinton
   is handling the transition.  All those who think that it's time the
   poll-takers went out and got real jobs, raise your hands.  I thought so.
From: maurel@mimosa.unice.fr (Maurel Frederic)
Newsgroups: comp.graphics
Subject: PHIGS for PC
Date: 7 Dec 92 09:04:27 GMT
Organization: University of Nice-Sophia Antipolis
NNTP-Posting-Host: mimosa.unice.fr


 Where can I find PHIGS for PC (or SPHIGS --> shareware) :
sources or executable.

Thanks 

-- Frederic MAUREL --
From: kiki@bass.bu.edu (Keith Baccki)
Newsgroups: comp.graphics
Subject: Re: Public Domain Renderers ?????
Date: 14 Dec 92 01:38:35 GMT
Reply-To: kiki@bass.bu.edu (Keith Baccki)
Followup-To: comp.graphics
Organization: Boston University

In article <Bz3uns.7KI@ra.nrl.navy.mil> yiannis@prologos.nrl.navy.mil (John Michopoulos) writes:
>
>
>Does any body know of Public Domain renderer (source code level) that  
>preferably understands .RIB files ???? Any renderer will do though ...
>
>We need to explore the possibility of rendering on a TM CM-5 ASAP. 
>


	Hmmmmm, not sure about the code. But I do know that rendering
on a Turing Machine is PAINFULLY slow... even if it's in parallel.


		
					keith
From: saeed@a.cs.okstate.edu (SAEED FAISEL)
Newsgroups: comp.graphics
Subject: Re: GOOD JPG VIEWER
Date: 19 Dec 92 01:01:39 GMT
Article-I.D.: a.1992Dec19.010139.29378
Organization: Oklahoma State University

In article <1gt4vkINNijv@network.ucsd.edu> spl@szechuan.ucsd.edu (Steve Lamont) writes:
>In article <6937.48.uupcb@outlan.ersys.edmonton.ab.ca> darren.madu@outlan.ersys.edmonton.ab.ca (Darren Madu)  writes:
>>Does anyone have any good jpg viewer.
>
>Yes.

OK. So how about sharing with us ?

-- 

-----------------------------------------------------------------------
| Faisel Saeed                        e-mail: saeed@a.cs.okstate.edu  |
| Department of Computer Science                                      |
Newsgroups: comp.graphics
From: 4224_5142@uwovax.uwo.ca
Subject: Animator Pro File Formats
Organization: University of Western Ont, London
Date: Sun, 13 Dec 1992 16:43:28 GMT

Could anyone explain the file format for an Animator Pro COL or CEL file?
I have an outdated version of the original Animator, and the format has
some differences in the new version?

	E-mail would be appreciated in  egerter@obelix.gaul.csd.uwo.ca

Thanks in advance, Barry Egerter (WGT Systems, London Ontario, CANADA) 

*****************************************************************************
*       \\          //  _______   _______    egerter@obelix.gaul.csd.uwo.ca *
*        \\        //  //            |                                      *
*         \\  /\  //  ||   ___       |       Author of WGT graphics         *
*          \\//\\//   ||     \\      |       toolkit for 320*200*256 VGA    *
*           \/  \/ .   \\____// .    |  .    Version 3.0 Now Available      *
*                                            (Turbo C++ 1.0 or greater)     *
* Sprites  Color Cycling  Bitmap SFX  4-directional Scrolling  FLI routines *
*****************************************************************************
Newsgroups: comp.graphics
From: uad1077@dircon.co.uk (Ian Kemmish)
Subject: Re: Z Buffer Precision and Homogeneous Coordinates
Date: Tue, 15 Dec 1992 19:10:33 GMT

gg10@prism.gatech.EDU (GALLOWAY) writes:


>transform into planes."  The depth value gets normalized from the range
>[near, far] to [0, 1].
>
>If the viewing transformation matrix consists of only linear operations,
>translation, rotation, and scaling, then this appears to degrade the
>precision of the depth value.  In my current Z buffer-based renderer my
>Z buffer is an array of 32 bit floats.  I preform clipping in the 3D view
>space (or eye space) before perspective projection.
>
>
>Greg Galloway
>gg10@prism.gatech.edu
>
>
You're essentially trading accuracy for range.  If you can only
afford integers for depth values (either becasue you only have 16
bits or because you can't wait for all those floating compare
operations), then you definitely don't want to risk them
overflowing and/or wrapping round.  On the other hand, if you are
already using float with no problemsn, then you have little
incentive to change (basically, all you need is a number system that
can represent infinity:->) - in fact, unless you are happy at
visualising and doing mental arithmetic with homogeneous co-ordinates
in your head, you will find debugging takes a lot longer if you *do*
change.....

-- 
Ian D. Kemmish                    Tel. +44 767 601 361
18 Durham Close                   uad1077@dircon.co.uk
Biggleswade                       uknet!dircon!uad1077
Beds SG18 8HZ United Kingdom
Newsgroups: comp.graphics
From: gupta@ansoft.com (Suvajit Gupta)
Subject: Compression of plot data
Organization: Ansoft Corp. Pittsburgh
Date: Wed, 16 Dec 1992 20:24:52 GMT


I need to plot a graph with a very large number of points (15,000+)
on a screen/printer with a much lower resolution (say 1000x1000).
Joining all the input points is very wasteful and verbose since most
of the line segments don't even span a pair of adjacent pixels.  Is
there some standard method for compressing the input data to weed out
points that wouldn't affect the graphical display noticeably?  One
idea I had is to throw away the interior points of a run of nearly
colinear points.


Xref: sparky comp.graphics:12897 comp.graphics.animation:1324
From: tlilley@csugrad.cs.vt.edu (Tripp Lilley)
Newsgroups: comp.graphics,comp.graphics.animation
Subject: Re: Realistic 3D Studio usage
Date: 14 Dec 92 21:24:44 GMT
Organization: The MultiMedia Lab at Virginia Tech, Blacksburg, VA


   Personal preference: a VL-Bus 486-33 with accelerated 24-bit video, 400meg+
hard-drive, 16mb memory... 3D-Studio 2.0, AAPro 1.x (I have 1.0 currently,
and am awaiting 1.3), PoV-Ray 1.0, and 3Ds2PoV 1.6...  with these, I can 
model/animate/preview/render in 3D-Studio for most work, and ray-trace in PoV
for more demanding work (anything that benefits from use of true reflection/
refraction)

  as for the pc-bus being outdated, check out the VESA VL-Bus standard... 
32-bit currently, with extended specs for 64-bit (Pentium et al.) ... I say
33-MHz 486, since the VESA standard has recommendations for how many cards 
should be placed on the bus (related to timing issues) and a 50-MHz can't 
handle any VL cards on the bus (according to the spec... it can be tweaked)
while a 33-MHz can handle 2 in slots... both support 3 VL devices built-in...

the advantage to this setup is somewhat buried... PoV-Ray.  Currently, PoV is
(IMHO) the best PD renderer around.  Moreover, it's portable, and already 
compiled for most non-UNIX machines (saving you the work)... which means, with
3DS and PoV, you can model on the IBM, and then render on the IBM *and*  
whatever else you can get your hands on... 3Ds also supports distributed 
rendering (like a few of the mac programs)...

the bottom line, however, has little to do with price/performance issues...
no amount of machine speed will make up for a modeler/animator with which you
are uncomfortable... if it takes you 5 hours to render a model it took you
20 hours to create with a one modeler, and 7 hours to render a model created
in something you felt good with in 10-15 hours, you've saved 3-5 hours without
a lightning fast machine...

- t.





-- 
 USES disclaim;                                                      |^^\/^^| 2
 Tripp Lilley   -- tlilley@csugrad.cs.vt.edu                         | |\/| |
 The MultiMedia Lab of the Colleges of Architecture and Engineering  |_|  |_|
 Virginia Polytechnic Institute and State University         (silly ASCII logo)
Xref: sparky comp.graphics:12891 comp.sys.sgi:18016
From: kiki@bass.bu.edu (Keith Baccki)
Newsgroups: comp.graphics,comp.sys.sgi
Subject: Re: Polhemus Head Tracking / GL problem
Date: 13 Dec 92 02:19:38 GMT
Reply-To: kiki@bass.bu.edu (Keith Baccki)
Followup-To: comp.graphics
Organization: Boston University

In article <1992Dec9.013147.2709@u.washington.edu> chuckb@stein.u.washington.edu (Charles Bass) writes:
>I need more information to answer this question however I can
>give the following advice:
>
>1) Don't use the lookat(..) function in GL  there are
>singularities that will cause "interesting" behaviour.

	Not sure what you mean by interesting behaviour.
Might you be able to elaborate? Surely, you don't want
to restrict the use of lookat() (a very intuitive function
when combined with window() IMHO). What exactly are you
doing with lookat(), and what interesting behaviour does
it produce? Just curious.


>2) Be careful on how you set up your near and far clipping
>planes.  This range is mapped into a 16 bit range (I'm pretty
>sure it's 16 bit).  Thus if you do something like setting your
>near plane to .1 and your far plane to 10,000,000 you will get
>"interesting" behaviour. You want to set the near and far planes
>to be as close together as possible to maximize your resolution.

	Hmmm, not sure about the bit resolution (would guess it's
a long, not a short). Whatever. Again, I must ask what you mean by
interesting behaviour?!?!? Perhaps it's because you're viewing
volume is squat and it distorts the dimensions of your image?
(HINT: yes it is, and that's what it does ;) Far plane only sets
your far clipping plane - i.e. has no effect on the image other
than clipping beyond that distance. Near plane,however, defines
the shape of your viewing volume (together with the dimensions of 
your view plane in window()) So your above statement is misleading.
Any "interesting behaviour" is caused by your view plane dimensions
being disproportionate (is that a word?) to your near plane distance.
Think about it:
        .           .
       .            .
      .             |
     .|             |far
 eye. |near -->     | 
     .|             |
      |             |
       .            . 
        .           .
         .
          .

Your view volume is defined by near, far, and dimensions of your
view plane. Note that the viewplane dimension is ~2 X distance to
the near plane => big spread in perspective projection. Consider
putting the near plane twice as far as it is from the eye => the
spread of the volume becomes smaller. It's called "perspective",
it's a wonderful thing. Now, when using zbuffer(), I've been told
that it's accuracy depends on the far plane's distance - anyone
care to comment on this?



					keith

Newsgroups: comp.graphics,alt.graphics
From: lbernard@iiic.ethz.ch (Laurent Bernardin   (Berni))
Subject: OGI
Originator: lbernard@d19
Organization: Dept. Informatik, Swiss Federal Institute of Technology (ETH)
Date: Mon, 14 Dec 1992 10:44:39 GMT


Can anyone tell me where to find the specifications of the Open
Graphics Initiative (OGI)?
Please reply by E-Mail.

------------------------------------------------------------------
| "I tried to take a late|           Laurent Bernardin           |
| night piss, but the    |  computer science student, ETH Zurich |
| toilette moved so again|         lbernard@inf.ethz.ch          | 
| I missed." -The Pogues | Phone: +352/348132 or +41/01/3114245  |
------------------------------------------------------------------




Xref: sparky comp.graphics:13080 comp.graphics.animation:1388
Organization: Ministry of Education, Computer Center NETNEWS system V2.3
Date: Sunday, 20 Dec 1992 17:04:15 EST
From: Shih-Min Kao <NTHUS134@TWNMOE10.BITNET>
Newsgroups: comp.graphics,comp.graphics.animation
Subject: Looking for 16M colors VESA driver for ET4000 card.
Distribution: world

  I have an ET4000 card (with 1M RAM) which is capable to display 16M (true)
colors. I found a VESA driver called vesadriv.zip in SIMTEL20. It can display
65536 colors at most. I need a VESA driver which can display 16M colors on
my ET4000 card. I also need a TARGA file previewer which is able to display
16M colors.

     Thanks.

Shih-Min Kao
nthus134@twnmoe10.bitnet (or nthus134@twnmoe10.edu.tw)
Newsgroups: comp.graphics
From: sts@mfltd.co.uk (Steve Sherwood)
Subject: POV Ray Trace
Reply-To: sts@mfltd.co.uk
Organization: Micro Focus Ltd, Newbury, England
Date: Mon, 14 Dec 1992 16:31:11 GMT

Does anyone know the location of a program called 

    'Connect the Dots smoother v1.3' by Truman Brown ?

Steve

-- 
+-----------------------------------+------------------------+ Micro Focus
| Just like Pariah, I have no name, |    rm -rf *            | 26 West Street
| Living in a blaze of obscurity,   |      "rum ruff splat"  | Newbury
| Need courage to survive the day.  |                        | Berkshire
+-----------------------------------+------------------------+ England
      Extn 5543, sts@mfltd.co.uk, !uunet!mfocus!sts
Newsgroups: comp.graphics