1.1 Opengl: Rain Water Harvesting
1.1 Opengl: Rain Water Harvesting
CHAPTER 1
INTRODUCTION
1.1 OPENGL
OpenGL is the abbreviation for Open Graphics Library. It is a software interface for
graphics hardware. This interface consists of several hundred functions that allow you, a graphics
programmer, to specify the objects and operations needed to produce high-quality color images
of two-dimensional and three-dimensional objects. Many of these functions are actually simple
variations of each other, so in reality there are about 120 substantially different functions.The
main purpose of OpenGL is to render two-dimensional and three-dimensional objects into the
frame buffer. These objects are defined as sequences of vertices (that define geometric objects)
or pixels (that define images).OpenGL performs several processes on this data to convert it to
pixels to form the final desired image in the frame buffer.
1.2 HISTORY
As a result, SGI released the OpenGL standard In the 1980s, developing software that
could function with a wide range of graphics hardware was a real challenge. Software developers
wrote custom interfaces and drivers for each piece of hardware. This was expensive and resulted
in much duplication of effort.
By the early 1990s, Silicon Graphics (SGI) was a leader in 3D graphics for workstations.
Their IRIS GL API was considered the state of the art and became the de facto industry standard,
overshadowing the open standards-based PHIGS. This was because IRIS GL was considered
easier to use, and because it supported immediate mode rendering. By contrast, PHIGS was
considered difficult to use and outdated in terms of functionality.
SGI's competitors (including Sun Microsystems, Hewlett-Packard and IBM) were also
able to bring to market 3D hardware, supported by extensions made to the PHIGS standard. This
in turn caused SGI market share to weaken as more 3D graphics hardware suppliers entered the
market. In an effort to influence the market, SGI decided to turn the Iris GL API into an open
standard.
SGI considered that the Iris GL API itself wasn't suitable for opening due to licensing and
patent issues. Also, the Iris GL had API functions that were not relevant to 3D graphics. For
example, it included a windowing, keyboard and mouse API, in part because it was developed
before the X Window System and Sun's NEWSsystems were developed.
In addition, SGI had a large number of software customers; by changing to the OpenGL
API they planned to keep their customers locked onto SGI (and IBM) hardware for a few years
while market support for OpenGL matured. Meanwhile, SGI would continue to try to maintain
their customers tied to SGI hardware by developing the advanced and proprietary Iris Inventor
and Iris Performer programming APIs.
• Stable
OpenGL implementations have been available for more than seven years on a wide
variety of platforms. Additions to the specification are well controlled, and proposed
updates are announced in time for developers to adopt changes. Backward compatibility
requirements ensure that existing applications do not become obsolete.
All OpenGL applications produce consistent visual display results on any OpenGL
APIcompliant hardware, regardless of operating system or windowing system.
• Evolving
Because of its thorough and forward-looking design, OpenGL allows new hardware
innovations to be accessible through the API via the OpenGL extension mechanism. In
this way, innovations appear in the API in a timely fashion, letting application developers
and hardware vendors incorporate new features into their normal product release cycles.
• Scalable
OpenGL API-based applications can run on systems ranging from consumer electronics
to PCs, workstations, and supercomputers. As a result, applications can scale to any class
of machine that the developer chooses to target.
• Easy to use
OpenGL is well structured with an intuitive design and logical commands. Efficient
OpenGL routines typically result in applications with fewer lines of code than those that
make up programs generated using other graphics libraries or packages. In addition,
OpenGL drivers encapsulate information about the underlying hardware, freeing the
application developer from having to design for specific hardware features.
• Well-documented
Numerous books have been published about OpenGL, and a great deal of sample code is
readily available, making information about OpenGL inexpensive and easy to obtain.
The following diagram illustrates how OpenGL processes data. As shown, commands
enter from the left and proceed through a processing pipeline. Some commands specify
geometric objects to be drawn, and others control how the objects are handled during various
processing stages.
• Display list
Rather than having all commands proceed immediately through the pipeline, you can
choose to accumulate some of them in a display list for processing later.
• Evaluator
The evaluator stage of processing provides an efficient way to approximate curve and
surface geometry by evaluating polynomial commands of input values.
OpenGL processes geometric primitives - points, line segments, and polygons all of
which are described by vertices. Vertices are transformed, and primitives are clipped to
the viewport in preparation for rasterization.
• Rasterization
• Per-fragment operations
These are the final operations performed on the data before it is stored as pixels in the
frame buffer Per-fragment operations include conditional updates to the frame buffer
based on incoming and previously stored z values (for z buffering) and blending of
incoming pixel colors with stored colors, as well as masking and other logical operations
on pixel values.
• Pixel operation
Input data can be in the form of pixels rather than vertices. Such data which might
describe an image for texture mapping skips the first stage of processing and instead
processed as pixels in the pixel operation stage.
• Texture memory
The result of pixel operation stage is either stored as texture memory for use in
rasterization stage or rasterised and resulting fragment merged into the frame buffer just
as they were generated from the geometric data.
Most of our applications will be designed to access OpenGL directly through functions in
three libraries. They are
• GL – Graphics Library
Functions in the main GL (or OpenGL in Windows) library have names that begin with
the letters gl and are stored in a library usually referred to as GL (or OpenGL in
Windows).
This library uses only GL functions but contain code for creating common objects and
simplifying viewing. All functions in GLU can be created from the core GL library but
application programmers prefer not to write the code repeatedly. The GLU library is
available in all OpenGL implementations; functions in the GLU library begins with the
letters glu.
To interface with the window system and to get input from external devices into our
programs we need at least one more library. For the X window System, this library is
called GLX, for Windows, it is wgl, and for the Macintosh, it is agl. Rather than using a
different library for each system, we use a readily available library called the OpenGL
Utility Toolkit (GLUT) , which provides minimum functionality that should be expected
in any modern windowing system.
The above figure shows the organization of the libraries for an X Window System
environment.
#include<GL/glut.h>
or
#include<GLUT/glut.h>
Our basic model of a graphics package is a black box, a term that engineers use to denote
a system whose properties are described only by its inputs and outputs; we may know nothing
about its internal workings.
• Primitive function: The primitive functions define the low-level objects or atomic entities
that our system can display. Depending on the API, the primitives can include points, lines,
polygons , pixels, text, and various types of curves and surfaces.
• Attribute functions
If primitives are the what of an API – the primitive objects that can be displayed- then
attributes are the how. That is, the attributes govern the way the primitive appears on the
display. Attribute functions allow us to perform operations ranging from choosing the
color with which we display a line segment, to picking a pattern with which to fill inside
of a polygon.
• Viewing functions
The viewing functions allow us to specify various views, although APIs differ in the
degree of flexibility they provide in choosing a view.
• Transformation functions
One of the characteristics of a good API is that it provides the user with a set of
transformations functions such as rotation, translation and scaling.
• Input functions
For interactive applications, an API must provide a set of input functions, to allow users
to deal with the diverse forms of input that characterize modern graphics systems. We
need functions to deal with devices such as keyboards, mice and data tablets.
• Control functions
These functions enable us to communicate with the window system, to initialize our
programs, and to deal with any errors that take place during the execution of our
programs.
• Query functions
If we are to write device independent programs, we should expect the implementation of
the API to take care of the differences between devices, such as how many colors are
supported or the size of the display. Such information of the particular implementation
should be provides through a set of query functions.
CHAPTER 2
SYSTEM REQUIREMENTS
CHAPTER 3
SYSTEM DESIGN
3.1 Flow Chart
START
Main() ;
myinit();
Display();
If
key=q
If
key=s
Stop If
Drawhouse( ); key=r
PostRedisplay();
Rain();
IdleFunction();
STOP
3.2 Initialization
• Initialize to interact with windows.
• Initialize to display mode that is double buffer and RGB colour system.
• Initialize window position and window size.
• Initialize and create window to display the output.
3.3 Display
• Rainwater Harvesting window will be displayed.
• Menus are created depending on the values returned by the menu.
• The operations performed are:
i. Create home.
ii. Rain.
iii. Exit.
CHAPTER 4
IMPLEMENTATION
4.1 OVERVIEW
This project is a demonstration of animation on “Rain water harvesting”. We have taken the help
of built in functions present in the header file. To provide functionality to our project we have
written sub functions. These functions provide us the efficient way to design the project. In this
chapter we are describing the functionality of our project using these functions.
Keyboard interaction
1. Firstly, after compiling and running the program we get the display of animation.
2. Then if we press the key s the animation of house is created.
3. If the key “ r” is pressed it starts raining.
4. If the key ”q” is pressed then the process will quit.
4.3 STRUCTURE
int main(int argc,char**argv)
void myinit()
void mykey(unsigned char key,int x,int y)
void display()
void rain1()
void drawhouse()
void drawpump()
void drawtank()
void bitmap()
void draw_pixel()
glutInit(&argc,argv);
glutInitDisplayMode(GLUT_DOUBLE|GLUT_DEPTH|GLUT_RGB);
glutInitWindowPosition(0,0);
glutInitWindowSize(1250,750);
glutCreateWindow("RAIN WATERHARVESTING");
myinit();
glutDisplayFunc(display);
glutIdleFunc(idle);
glutKeyboardFunc(mykey);
glutMainLoop();
4.3.2myinit:
void myinit() {
glClearColor(0.0,0.0,0.0,0.0);
glColor3f(1.0,0.0,0.0);
glPointSize(1.0);
glMatrixMode(GL_PROJECTION);
gluOrtho2D(-750.0,400.0,-500.0,400.0);
{ key2=key;
if(key==27)
exit(0);
if(key=='q'||key=='Q')
exit(0);
if(key=='s'||key=='S') {
drawhouse();
bitmap1();
} if(key=='r'||
key=='R')
count=150;
drawhouse();
rain1();
rain35();
4.3.4 Display
void display()
glClear(GL_COLOR_BUFFER_BIT);
glPointSize(2.0);
bitmap();
if(key2=='q'||key2=='Q')
exit(0);
if(key2=='s'||key2=='S')
drawhouse();
if(count1>150)
line();
bitmap1(); }
} if(key2=='r'||key2=='R')
count=count+1;
drawhouse();
bitmap();
line();
bitmap1();
if(count<2500)
rain1();
if(count>370&&count<3600)
flow1();
if(count<3620)
flow2();
if(count>300&&count<4030)
{ disprectangle2();
disprec();
if(count>500&&count<3730)
flow3();
if(count>520&&count<3750)
flow4();
if(count>540&&count<3770)
disprectangle();
if(count>1530&&count<4250)
flow5();
if(count>1500&&count<4480)
square();
if(count>1560&&count<4300)
flow6();
if(count>1600&&count<4320)
flow7();
if(count>1620&&count<4340)
flow8();
if(count>1660&&count<4360)
flow9();
if(count>1690&&count<4380)
flow10(); if(count>1790)
disprectangle1();
} glFlush();
glutSwapBuffers();
void rain1() {
int k,l;
glPointSize(4.0);
for( k=24;k>=0;k--)
if(rainpoint1[k][1]==-60.0)
rainpoint1[k][1]=400.0;
for( l=1;l<=24;l++)
glBegin(GL_POINTS);
glColor3f(0.0,0.5,1.0);
glVertex2fv(rainpoint1[l]);
glEnd();
for(i=23;i>=0;i--)
rainpoint1[i][1]=rainpoint1[i][1]-2;
rain3();
CHAPTER 5
SNAPSHOTS