PDA

View Full Version : How to get contour lines on 3D volume



billywen88
02-11-2015, 12:16 AM
Hi, developers
I am making some 3D volumes from x,y,z, colorlevel data using OpenGL ES 2.0 in Android.
so the volume created as like follows.
1626

then I couldn't make contour visible sides of volume at a user specified contour interval.

and also I couldn't make contouring this volume to 2D as like as follow.

1627

I want to know how to contour this volume at some interval in OpenGL ES 2.0.

carsten neumann
02-11-2015, 09:42 AM
OpenGL can not help with that, since it is purely a rendering API. You need an algorithm that can extract an iso surface (or iso line in the 2D case) from a scalar field; one algorithm that can do that is "marching cubes". The mesh produced by such an algorithm can then of course be rendered by OpenGL.

Carmine
02-12-2015, 11:50 AM
You are going to have to write 2D contouring or 3D iso-surface codes. This is not trivial. Have you thought about bringing your data into an application like Matlab? It will do the contouring and surfacing for you.

carsten neumann
02-12-2015, 03:32 PM
That is a good point, open source (e.g. ParaView) and commercial (e.g. Amira) visualization software can do this too.

The Little Body
02-19-2015, 03:53 PM
This can perhaps to be make using Z values generated on the zbuffer ?

You have only to read the zbuffer line by line for to have the x, y and z values for each slice
(this need of course to redraw the volume in the other side for to have entires contours, not only the half)

Or using clipping planes for to draw each slice one per one ?
(for each slice, one clipping plane a little over and another a little below, with a different color for each slice )
[in your terrain picture, this seem to need only about ten slices]

GClements
02-19-2015, 04:52 PM
This can perhaps to be make using Z values generated on the zbuffer ?
No.


(this need of course to redraw the volume in the other side for to have entires contours, not only the half)
You're assuming that the contours are convex, but there's no reason to believe that assumption is valid.

The Little Body
02-20-2015, 02:10 PM
Effectively, contours are generally concaves and not convex :(


This is more the second idea about to create a distinct slice for each distinct materials/depths/altidudes possibles values that seem cool :)

We make one distinct slice for each depth/elevation map possibles values entries

Where each slice X represent the map of where the material X is present

In the slice 0, we store the index 0 where the detph/elevation/color map is equal to the material 0 (for example, the ground)
In the slice 1, we store the index 1 where the detph/elevation/color map is equal to the material 1 (for example, a wall)
...
In the slice X, we store the index X where the deth/elevation/color map is equal to the material X (for example, another wall)
...
In the slice 255, we store the index 255 where the deth/elevation/color map is equal to 255 (for example, the sky that can to be see as the the more distant possible material)



=> with 4 bits per slice, this seem to can handle pictures like your terrain elevation map with 16 differents elevations values entries

==> with 8 bits per slice and 256 slices, this can handle 256 distincts/differents materials
(where ground and sky are **only** 2 materials into this palette, so 253 entires are free for others materials like walls, desks, persons ...)

The 256 materials palette possibles entries can to be extended for to store a distinct plane equation for each material if we want handling the fact that the ground, sky and walls are generally perpendiculars for example

=> this 256 planes equations palette can perhaps to be used for to construct something like a "paletted BSP" ?

Slices are on very good format for to be compressed because they store only two values 0 or X, so 1bpp
(0 if nothing is present here and X if the objet present here have the material X)


The next step seem now to can raytrace on realtime this 256 planes/slices/materials BSP palette for each pixel displayed on the screen :whistle:

=> the version with only 16 distincts depth/elevation/colors/planes/slice/materials maps values can perhaps to be handled via a pixel shader for example ?
(with multitexturing and 4 RGBA textures, we can already handle 16 differents depths/altitudes/elevations/depth/slices/materials map values entries or 4 planes equations for example)