Re: [GtkGLExt] =?utf-8?q?Is_it_possible_to_use_overlays_with_gtkglext?= =?utf-8?b?bW0/?=




    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: [SPAM] 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'





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]