Hi, Beyond the final rendering lib used (OpenGL or DirectX or whatever), the most discriminant thing is the projected use.
To be more precise : if you want to use your data for creating a 3D surface using IDW (theory is widely known and used, and algorithm is straightforward, google will help you without problem), I don't understand why you'd need a TIN, unless you want to perform a very complex data mix from interpolation of scattered points and mesh data. You may use a TIN (search for Delaunay triangulation), if your point data is defining very accurately the surface to be constructed (like points from contour lines). Building a TIN straight from your point data will create a surface honorring all points, without under/overshoots nor any smoothing. Beware, this doesn't mean that there can't be any smoothing at rendering time: you may alter crease angle, derive a spline surface from the TIN or use it to create local BezierPatches for example. But the surface description itself will be fitting your point set. You may use IDW if you want a surface that *approximates* a best fit of your point set. You won't have any under/overshoot, but your surface will be very smoothed in the end, and the process is very mainly used to produce a DEM (a matrix of points), though nothing prevents you to qualify a set of scattered points using IDW, though I can't see the reason why one should do this. Other algorithms can be used to build an approximation of the surface : gridding, fifth order interpolation, etc ... each of these won't ensure agains under or over shoots, but you may choose wether you allow over *or* undershoots, depending on your needs. for example : for submarine navigation you'd prefer allowing overshoots rather than undershoots ... while a smoothed IDW surface is of no use ... while a atmospheric inversion surface would be better represented smoothed by an IDW ... So, the algorithm used for surface reconstruction depends on the quality of your pointset, the data represented, and the projected use of the surface. Now, more generally speaking, from a representation standpoint. You may have understood that the data can be described as a TIN or a mesh. A mesh will always be smoother than a TIN. May be good, may be bad ... depends. For example, you'll never be able to represent a vertical cliff or a flat lake or road using a mesh, no matter the points spacing. Next, what do you need to use to transmit your surface representation, I mean as a medium ? If you want to publish it thru any small Internet wiring, a DEM is usually more concise (lightweight) than a TIN. If this is an urgent point then this may decide. But beware, if you want to represent almost vertical surfaces precisely (cliffs, houses ...) then you need a very small spacing for the points of a mesh ... so a very big footprint ... much much bigger than what you could achieve with a TIN. If you decided what representation you want, then for the draping. ... There's no real difference in draping a mesh or a TIN. What is needed is to define for each point (of a mesh or a TIN) a correponding point in the raster, usually expressed as a percentage of u,v raster coordinates (a bit like MI is doing ... but, cleverly, 3D Engines are twisting the raster and *not* the vector !, MI is the only tool I know persisting in nonsense, but that's another rant). However, if you use orthorectified images, then the process is straightforward. Most important for the draping : the raster size. Beyond the obvious download weight, any rendering engine will accept raster only up to some size (directX or openGL). If the size is too big, the raster is scaled down automatically. A good advice is to never go beyond 1024*1024 pixels. This is very important, because this may mean tiling your geometry to fit small raster tiles... And this is *the* point : it's very easy to slice a mesh geometry ... and much harder to slice a TIN geometry... The final step is the rendering engine. The easiest one .... I, for myself, do prefer using VRML. VRML ensures a widespread display ability thru systems, OSes, an easy Internet capability, and a vendor independance. Note that the same VRML engine may be used on top of DirectX or OpenGL. It provides a higher level abstraction layer. Of course, one more layer causes less framerate, but the advantages are sooo big. AMAF, I achieve more than 30 fps on a 1000 square km TIN ground draped with 50 cm/pixel orthoimagery (more than 300 000 triangles on 500 square meters tiles) on a standard machine (well, almost ... Pentium 2GHz, Win XP, GEForce4 126 Megs). Do you need more ? ... So the renderer choice isn't the point. Usefull (very) link : www.geovrml.org look for Chris Thorne slicers, use Cortona for display (has got a native c++ GeoVRML implementation) or if you're a JAVA fanatic (I'm not) use standard java libraries. If you want to keep it KISS, look in the MI-L archives for DEM and VRML, I posted two years or so an example for creating a DEM representation in VRML using MI and Notepad... Hope have been clear enough... :/ 3D is a bit complex to explain at midnight ... BTW, for those interested, watch my site (www.geovrml.com) in the coming month, I hopefully, find some time for presenting my latest project : a virtual forest fire fighting, collaborative and immersive training tool. Very impressive screenshots. Have a nice day. Eric. Eric Maranne EMI Informatiques : www.geovrml.com (33)(+) 4 42 06 22 22 Port de Bouc - France : http://www3.calle.com/info.cgi?lat=43.4000&long=4.9833&name=Port%2dde%2dBouc &cty=France&alt=0 43? 23' 60N 4? 58' 60E Alt: 0 > -----Message d'origine----- > De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Envoye : vendredi 17 mai 2002 15:31 > A : [EMAIL PROTECTED] > Objet : Re: MI-L 3D generation > > > > >> generate 3D surface models without using any GIS package. > > You might want to try OpenGL. > > http://www.sulaco.co.za/opengl4.htm > http://nehe.gamedev.net/ > > or try Goooooogle. > > > Jakob > ****************************************************************** > ************ > > Jakob Lanstorp. M.Sc. > Developer > Kampsax A/S, > GIS Software & Solutions, > Rugaardsvej 55, DK-5000 Odense, Denmark > tel: +45 6313 5000, dir:+45 6313 5011, fax: +45 6313 5090 > Mailto:[EMAIL PROTECTED] - http://www.kampsax.dk > Authorized MapInfo Partner & Distributor in Denmark and Norway. > ****************************************************************** > ************ > > See Denmark from above on: http://www.kortal.dk > > > > > > Jakob > > Lanstorp Til: Jakob > Lanstorp/Kampsax@Kampsax > cc: > > 17-05-2002 Vedr.: MI-L 3D > generation > 15:22 > > > > > > > > > > > Hi All > Though a bit off the track. > > I want to embark on a new assignment. > I have point data - from which I have to generate 3D surface > models without > using any GIS package. (using C/C++) > Can anyone direct me to some good URL's of algorithms/ > theory/freewares for > IDW/TIN/DEM/Draping/VRML > > > TIA > Deepak Kaul > > > > > > > > --------------------------------------------------------------------- > List hosting provided by Directions Magazine | www.directionsmag.com | > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > --------------------------------------------------------------------- > List hosting provided by Directions Magazine | www.directionsmag.com | > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
