neteler at geog.uni-hannover.de
Tue Jan 23 12:12:09 EST 2001
On Tue, Jan 23, 2001 at 10:08:44AM -0600, Helena Mitasova - staff wrote:
> NVIZ issues:
> >just curious: How did you/Bill generate these nice images? Which
> >projection did you use?
> 1.the globe is done from latlong data in SG3d, you can have 3D terrain, color
> and vectors draped on it. It was done by Bill. I am not sure whether
> this is available in NVIZ (I don't have latlong data to try it,
> if it is not supported it should be added to my list of things
> which were in SG3d and are not in NVIZ.)
I have lat/long GLOBE DEM 30'' data here. They work well with NVIZ except
the general color bug in case of low view angles (I think the decrease
value ist just too large, which reduces the light if you lower the view
> 2. I believe that the -q problem with NVIZ was fixed so you can remove it
> from my list.
> 3. Also, do you have the GL version of nviz (it should be nviz2.1, I believe)?
> It may be useful to make it available for developers so that the Open GL
> and GL handling of lights/normals could be compared. That version should
> also draw a flowline when you click on a surface with "What is here" option
> (instead of drawing a line from the previous point) If you don't have
> it I will find it on GMSL machines and put it on our webserver for you
> (sorry if I am asking the same question that I asked already)
No, I never had this version if I recall correctly. Jaro Hofierka sent
his ported NVIZ2.2 that time, but never NVIZ2.1. However, the ogl3d is
in CVS in src.contrib/GMSL/.
> the examples with NVIZ lights are at
> >I'm not sure if I replicated "the bug" or not. After loading in a large surface
> >(2300x2500) I increased the z
> >exaggeration to about 35 and most of the map was dark. It appeared to be
> >only a small portion of pixels were being rendered with bright colors
> yes that is it, although I did not play around with the Follow ViewPoint,
> but I believe that all the following problems are related to light,computation
> of normals and/or angle between the line of sight from the viewer
> and a surface normal and/or some initial settings/hard coded constants, related to
> a) light not working when the surface values are decimals between 0.- 1.0
> b) parts of the surface not being rendered for certain combination of viewing
> position, exagerration, size of the raster, etc... (see the example images above,
> it seems that it "thinks" that some parts of the surface are hidden, so
> it does not render them, while they are actually visible)
> c) light is more difficult to use in NVIZ than it was in SG3d, in spite
> of the same concept - it may actually be useful to look into SG3d to
> see how the light is set-up there and compare it to NVIZ.
> >One thing I noticed is that we may want to change the lighting controls,
> >they do not seem very intuitive to me, but that's just my opinion.
> You are right that the lights are not too easy to use in NVIZ, but I
> don't think that it is in the type of controls, although they could
> be enhanced too, e.g. by adding N,E,W,S etc.,
> The real problem is in settings.
> When you start SG3d the light is about right and it is higher than in NVIZ.
> All what I usually did was moving the dot in the viewing angle square around
> its perimeter to get it lighted from different sides. Almost never had I
> gone with the dot to the center, unless I needed some special effect.
> In NVIZ, the light starts too low and the lighting which you get when moving
> the dot around the perimeter is inadequate. You have to move the dot
> close to the center to get suitable light and work around there - this is
> indeed very un-intuitive. Also the height of the light source is set too low
> and even on maximum it never gets to the height as it was in SG3d.
> It would be useful to see what were the defaults, initial settings and
> scaling of light parameters in SG3d and see whether it would be possible
> to fix this in NVIZ - it may make NVIZ much more pleasant to use.
> >it seems that interrupting the render process is not truly interruptive.
> >While playing around with the lighting I interrupted the render many
> >times, yet when I stopped and let the render finish it flashed between
> >wire frame and rendered surface several times. This seems to indicate
> >that the commands were being queued somehow.
> that may be true, although I am not sure whether this was addressed by Bob
> Covill's changes or not.
> As this email is getting too long I put a compilation of email exchanges
> that we had about the normals at
> Bill was supposed to look at these issues weeks ago but haven't
> heard from him for quite a while.
> If you want to unsubscribe from GRASS Development Team mailing list write to:
> minordomo at geog.uni-hannover.de with
> subject 'unsubscribe grass5'
Markus Neteler * University of Hannover
Institute of Physical Geography and Landscape Ecology
Schneiderberg 50 * D-30167 Hannover * Germany
Tel: ++49-(0)511-762-4494 Fax: -3984
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'
More information about the grass-dev