Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Results 1 to 6 of 6

Thread: updating an existing opengl window

  1. #1
    Junior Member Newbie
    Join Date
    Jul 2002
    Posts
    13

    updating an existing opengl window

    Hi,

    Thanks for all your help getting started with glut, Rob

    Cld anyone offer some advice about taking input(vertices) to add to an existing display window? Or let me know where I might find some info about it...

    Thanks.

  2. #2
    Junior Member Regular Contributor
    Join Date
    May 2002
    Location
    York, UK
    Posts
    128

    Re: updating an existing opengl window

    So, if I get you, you have a display func doing its stuff. You read in some new extra vertices (or create whatever) and want to add them in ...

    In your display func you need to have code which processes a dynamic structure of some kind which represents your data. You then add to this structure and update a variable to tell the display func how many elements to process in the structure.

    So, the simplest, and least elegant could be an array of vertices, somthing like:

    Typing direct to this thread! So treat as sort of pseudo code (ie don't expect the code to work exactly!)

    #define MAXVERTS 1000

    typedef vertex { GLfloat x; GLfloat y; GLfloat z; };

    vertex myverts[MAXVERTS];
    int lastvert=0;

    .... in the display func

    for (i=0; i<lastvert; i++ ) {
    glvertex3f ( myverts[i].x, myverts[i].y,myverts[i].z );
    }

    ... later add more vertices to myverts, and update the variable "lastvert", magically more vertices are shown!

    of course you can use the "v" variants such
    as glvertex3fv() ...

    Idea above to demonstrate *a* technique.

    Better still though is a linked list rather than array.

    If you want the vertices to represent different "objects", the think about having a data structure to represent an "object" and any attributes of each object can be stored in here and processed in each pass through the "display loop". e.g. colour, texture map, blend funcs, movement, visibility, updates
    etc ...

    Then, have a list of these.

    There are numerous ways to do this sort of thing. Basically you are looking at scene trees in various forms. Check the web.

    One solution I did was to create a generic object (so even the rendering function was part of the object, so e.g. you could render as a sphere, and then next frame change the render function to render as a cube, or whatever!). I then created a dynamic list of these objects (one attribute of an object of course was a list of other objects, so you can easily do flocks!), and called this the "object store". Dynamic, so you can delete objects no longer required. My work consisted of lots of "scenes" related to sections of a music score (but the graphics rendering in each scene were controlled by the performer, score following software, audio processing of the sounds and also some auto behaviour of the object itself!).

    So, I then added the notion of a scene workbox. In this you put pointers to the objects you needed to render (from the store). You basically "layer up" this box
    to get the "z ordering" you wanted. Of course, an object can appear more than once in this box at different "z depths"! Special objects exist which can be placed in the box to control things like depth buffer on/off and other more "global" and not object specific rendering functions.

    Anyway, the purpose of explaining this is to give you some idea how to think about YOUR application.

    I was given 3 weeks to design and write this whole system. The API is quite big, but has calls like createObject(), addObjectToObject), setObjectColour(), setObjectVisibility(), and so on ... and of course, for every "set" there's a "get" ...

    The system also has a full particle simulation system in it too to do flame, smoke and explosion type effects along with all the other gubbins!

    I also added the notion of "render systems" so the display loop basically rendered the "RIMM objects", then "Particle Objects", and so on ... adding in another render system in to the chain is then easy.

    RIMM == Realtime Interacive Multiple Media

    Rob.

  3. #3
    Junior Member Newbie
    Join Date
    Jul 2002
    Posts
    13

    Re: updating an existing opengl window

    wow sounds like u're really experienced...

    I've been playing around with my program the last few days, trying out different things. I'm still a little confused as to how to add additional points once the initial rendering is done.

    Once glutMainLoop is called, no other code is executed...I've set up my display function to draw the vertices in the structure, but I can't see how to actually add the points to the structure...

    [This message has been edited by yaba (edited 07-30-2002).]

  4. #4
    Junior Member Regular Contributor
    Join Date
    May 2002
    Location
    York, UK
    Posts
    128

    Re: updating an existing opengl window

    Pop some code to update the structure into a keyboard callback function ...

    One of my systems checked for input on a UDP socket in the "idle" fucntion ... so a remote machine could send control data to the graphics rendering machine! So, check the use of the "idle" function too ...

    Basically, if registered, then this will be called once the rendering has been done to mop up the any "cpu idle time" ...

    Rob.

  5. #5
    Junior Member Newbie
    Join Date
    Jul 2002
    Posts
    13

    Re: updating an existing opengl window

    oic..what about having multiple machines, each doing some of the rendering to a single window on 1 machine and at different times? is that possible? maybe using glutSetWindow..although I'm not sure the opengl program structure will allow it..it seems to me that a particular window can only be controlled by the process that started it?

  6. #6
    Junior Member Regular Contributor
    Join Date
    May 2002
    Location
    York, UK
    Posts
    128

    Re: updating an existing opengl window

    Hmmm different machines rendering to the same graphics context on one machine ... not really possible. You are into the realms of distributed graphics.

    Check out http://www.cs.unc.edu/~pxfl/

    for where things went ...

    My systems allowed other machines to control what was rendered ... the idea was to use the most powerful rendering machine, and then to allow other machines to decide what was rendered and how that rendering was drawn, animated etc etc ...

    Rob.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •