[GtkGLExt] (resend) Re: Is it possible to use overlays with gtkglextmm ?

[axora axora net]

    There's many ways to slice an orange :P


    First of all, all one needs to do is scan through the coordinates
and check for min/max ranges.  Because you will be gathering data from a
finite dataset (i.e. one wouldn't expect to use numbers of the
10^1000000 range for example!) you can then act on the given range as
appropriate.


    32-bit floats can reliably represent numbers in the integer range of
1^24, so if the data doesn't fit into it, you can use several methods. 
Data partitioning is one of them.  You can stuff your figures into
32-bit integers, or even 64-bit integers (post multiplied) and just send
the lower 16 or 32 bits to the vertex array according to the viewing
range.  It's free range-clipping.



    Also one can partition data into 8 volumes, each with their own
coordinate system (with a full dynamic range each of, say, 32 bits)
which is represented on-screen by offset rendering.


Regards,
        Jose.



  -------- Original Message --------
 Subject: Re: [GtkGLExt] Is it possible to use overlays with
 gtkglextmm?
 From: John Darrington <john darrington wattle id au>
 Date: Mon, February 15, 2010 7:04 am
 To: Jose Commins <axora axora net>
 Cc: gtkglext-list gnome org, Haraldur Tristan Gunnarson
 <harg pml ac uk>
 
 On Fri, Feb 12, 2010 at 05:42:13PM +0000, Jose Commins wrote:
 
 >>> of the requirements is to have the facility to view large files in
full
 >>> detail. Applying transformations globally and moving the points
away
 >>> from the origin also cannot work because OpenGL uses single
precision
 >>> floating point, which cannot handle the need for having coordinates
that
 >>> can express, with precision, values such as 20000.345, so I
currently
 >>> place the points around the origin, their coordinates subtracted by
 >>> offsets that change each time. Also, I have been using GTK because
the
 >>
 >> No need to use floating point by the way, and you can get round 
 >> single-precision quite easily by multiplying your values by, say,
1000 
 >> before storing them in your vertex array. There's a lot of headroom
in 
 >> there!
 >>
 >
 >But the tricky thing is to predict exactly what value to multiply by.
It's
 >a non-trivial problem, which whole PhD theses have investigated.
There's
 >even a website dedicated to the problem http://www.floatingorigin.com
 >
 >J'