[DotNet-OSGeo] RE: 3D display
hadunsford at gmail.com
Wed Jun 1 13:25:30 EDT 2011
DirectX supports very simple points and lines as colored vertices pretty
easily, but you will have to convert the double precision coordinates into
single precision floats. You can support more symbolic points and lines by
textured vertices and GDI drawing to create a bitmap that you convert into a
texture. You can vertices organized as two triangles that form a square for
points or an elongated rectangle for lines. You can have transparent
textures, so it's ok if your vertices are bigger than your shape. Remember
that traditional Z-ordering by drawing sequence is not really going to be
used in 3D since you will be working with 3D constructs. In order to fill
polygons properly by using triangles you have to do tessellation.
Alternately, you can draw them as a texture on a pair of triangles like with
points and lines. My experience is that DirectX did not support
tessellation directly, but OpenGL does. You can use Tao open GL in order to
get that to work in C#. So basically you could start with the mapwindow or
DotSpatial tools for reading the shapefiles themselves, pick a reference
scale in order to transform the geographic coordinates into floats, and then
use Tao OpenGL to get the tessellated polygons. I am not aware of any
existing tools that do that sort of thing other than what we created, but
there may be something out there now.
On Wed, Jun 1, 2011 at 12:34 AM, Carsten Troelsgaard <troelsgaard53c at live.dk
> Michael wrote
> There are packages that will do Shapefiles for you, know you?
> Yes. I'll eventually get to the libraries. But there are some
> considerations. I've always been or atleast felt alone in my coding quest.
> Noone tought me anything (that's not true). The net.framework is HUGE from a
> newbie point of view .. how do I know that it doesn't already contain what I
> need (as it did with the tif-encoder) without learning about the nooks and
> crannies of it - and that's an enormous task on it's own. Around easter I
> had a look at the libraries of two of the dotnet-projects. I was pleasently
> surprised. But I shyed away becourse of the overhead. My first exe-files
> turned out to be executable from my web-pages. It was and they still are so
> small and selfcontained, that they for 'some' practical reasons can function
> as a 'format': The little D2-polyLine editor contains the line-data and a
> continous abillity to edit it .. woila! It's an exe with no consequences,
> but it complies to a sound design-rule: keep it simple! It does no more and
> no less than it promises.
> There is a particular reason to do the 'copying' of classes that I do: I
> need to get to know the gis-world (I'm a geologist), and the laborious task
> of dealing practically with the details IS the learning-process. I get the
> classes too, fine.
> One of the reasons that I keep coding is the posibillity to .. over time ..
> build a library of 'good' classes. A library that I KNOW inside out. This
> sounds good, but the reallity is different. So few things survive time.
> Sometimes, after writing a class, I feel that I can tell if it's going to be
> usefull in the future .. and it's again the 'I can see what it does', and it
> does no more and no less. I spent most of my time trying to understand ..
> life is too short for cryptic classes. In this respect the dotnet libraries
> I looked at gets an A+.
> If there are small dll's that deals with the basic formats it would be
> stupid not to use them, but the shortcut may only be exploitable in the
> vb-editor becourse of the intelli-sense (I don't know where the
> intelli-sense went in my current C#-editor)
> DotNet mailing list
> DotNet at lists.osgeo.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the DotNet